[
https://issues.apache.org/jira/browse/SOLR-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Rafalovitch updated SOLR-10144:
-----------------------------------------
Security: (was: Public)
> 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
> 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
