[
https://issues.apache.org/jira/browse/SOLR-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16579803#comment-16579803
]
Sebastian Lutter commented on SOLR-10144:
-
I agree that Nested Documents needs to be better integrated in Solr to be
useful in certain use cases.
* It is bad to pollute the schema of the parent document with field for child
docs. And child documents should not carry all mandatory fields from their
parent schema. Internally some sub-schema mechanism is needed. How would your
scope syntax would look like? Like this? And the scope internally would be
something like a own schema?
{code:xml}
id
{code}
* An alternative would be to use FieldType for this, i.e.
{code:xml}
id
{code}
Despite the syntax I guess to make Nested Documents a first class citizen in
Solr (meaning: to integrate it in the standard query behavior without the need
for a ChildDocTransformer, manually defining fields to distinguish parents and
child as well as parentFilter that uses them) a lot of classes needs to be
changed. All classes involved in indexing and query documents need to be aware
that documents can occure in a nested document structure and that there is a
parent and child schemas. And the _root_ field as it exists right now should be
automatically used to distinguish between parents and child documents.
What are the future plans of the developers with nested documents in Solr? Are
there any plans to improve the integration in upcoming releases? Would be great
to get some insight here.
> 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 {{}};
> ## (!) 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=\*:\*=\*}} 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
