[
https://issues.apache.org/jira/browse/SOLR-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-10144:
------------------------------------
Description:
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]
was:
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">}};
# it can be _any_ level deep, and fan out _any_ subscopes ({{name}} necessary
for distinguishing {{sons}}, {{daugthers}} subscopes);
# (?) I'm not sure whether {{name}} is uniq or 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, where there should no
uniqueKey clash on child scope;
# 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.
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?)
# (!) unique id value should span whole block (?) oh'really?? _it seems like we
can avoid it_
# (?) 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]
> redesign block-join support
> ---------------------------
>
> Key: SOLR-10144
> URL: https://issues.apache.org/jira/browse/SOLR-10144
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> 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]
