You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mikhail Khludnev (JIRA)" <ji...@apache.org> on 2017/03/05 09:37:32 UTC
[jira] [Updated] (SOLR-10144) redesign block-join support
[ 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(!). 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]
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 (!);
# 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">}};
> # 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]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org