[jira] [Resolved] (SOLR-10144) redesign block-join support

["Mikhail Khludnev (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Khludnev resolved SOLR-10144.
-------------------------------------
    Resolution: Won't Fix

Closing in favor of SOLR-12298

> redesign block-join support
> ---------------------------
>
>                 Key: SOLR-10144
>                 URL: https://issues.apache.org/jira/browse/SOLR-10144
>             Project: Solr
>          Issue Type: Improvement
>          Components: query parsers, update
>         Environment: Java. https://wiki.apache.org/solr/HowToContribute
>            Reporter: Mikhail Khludnev
>            Priority: Major
>              Labels: gsoc2017, java
>
> This is a placeholder for new block join design. Let's comeup with the name first: -whether- it will be nested -child docs or blocks?- 
> h2. Feature Delivery plan
> h3. Naming
> Nested Documents
> h3. Scopes in schema.xml 
> # fields can be grouped with {{<scope name="parent" default="true">}};
> ## (!) such fields' scoping is not mandatory, postponable, might cause _rbdbms illusion_   
> # it can be _any_ level deep, and fan out _any_ subscopes (a scope {{name}} is necessary to distinguish between {{sons}} and {{daugthers}} subscopes);
> # (?) I'm not sure whether {{name}} is uniq globally or names in traverse path is unique. _I'd like the former_;
> # btw, maybe  {{type}} (?) ;
> # {{default}} attribute is necessary to map existing blocks, which has only one nesting dimension: {{childrenDocuments}};      
> # fields beside of scopes (_global_) can appear on any scope. it should work with uniqueKey(!). What's semantic of uniqueKey across scopes(?) One recently discussed case it searching for child scope documents, when children uniqKeys should not clash;
> ## root doc uniqueKey spans on whole block (it's necessary to be used as deleteTerm for block updates), but every doc is identified with own uniqueKey (otherwise it's not possible to find it with distributed search)
> # coming to roots (?) how many root scopes we can have? _I think we can have a few ones that introducing notion of document types._ 
> h3. Updates
> # All formats XML, JSON, JSONdoc, Javabin accept nesting in named scopes;
> # Current format (unnamed nesting) is supported by {{default}} marked scope;
> # field are accepted only if they are defined at the certain scope, beside of the _global_ ones. (see consideration above)
> h3. Default experience 
> *# submitting {{q=\*:\*&fl=\*}} responds root documents with all children from all subscopes nested in according to the scopes hierarchy. i.e. \[child] is *on* by default
> *# {{fq=}} aims root docs
> h3. Query
> # let's follow -Elastic- JSON.facet idea, and piggyback on its' request parsing facilities;   
> # this query should contains of nested query nodes, every node represent \{!parser param=baram v='input'};
> # this syntax should have handy defaluts/shortcut, to search {{foo:bar}} in less than fifteen brackets,quotes and commas;
> # it should use existing QParsers including \{!func} ;
> # searching scopes is supported by _named scope_ QParser, handled in this syntax by regular way;
> # subscope query should be easily hooked in any occur (should, must, not )  ;
> # it should be available in a dedicated \[transformer], and support the following scenarios: search parents by certain children, return them nested in response _without repeating query_, do the same but return all children of selected parents   ;
> # naming standalone nodes and referencing them is cool.    
> h3. Update/deletes/uniqueness/versioning
> # delete query/id hits root docs, and also nukes subordinate children;
> # updating existing root doc completely removes existing subdocs, and replace all of them with the new ones ;
> # field update fully rewrites whole doc hierarchy, and can aim any subdoc in hierarchy (this won't be easy, how to identify children?)
> # (?) do we need to identify separate subdocs with id? probably _yes_ for field updates  
> # _version_ should span whole block (_If I've got the recent SOLR-10114 right_) 
> h3. Faceting
> # subject for support by Json.facet
> h3. Named scopes support in DIH
> # _Old sport_, you know.
> h2. Inception
> [comment|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855698&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855698] and [the next one|https://issues.apache.org/jira/browse/LUCENE-7674?focusedCommentId=15855708&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15855708]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org