[
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">}};
# 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 (!);
# 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]
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 (they are necessary
for distinguishing {{sons}}, {{daugthers}})
*# (?) I'm not sure whether {{name}} is uniq or traverse path is unique. btw,
maybe {{type}} (?).
*# {{default}} attribute is necessary to map existing blocks, which has only
single nesting dimension: {{childrenDocuments}}
*# fields beside of scopes (_global_) can appear on any 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 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 separate nodes and named references 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 one
*# 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">}};
> # 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 (!);
> # 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]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
