[
https://issues.apache.org/jira/browse/SOLR-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16538657#comment-16538657
]
David Smiley commented on SOLR-12519:
-------------------------------------
Judging from TestPathHierarchyTokenizer (e.g. testStartOfCharEndOfDelimiter),
if you put a trailing '/' at the end of the input, then it's retained in the
indexed token for the full path and you can then query by this. In this way,
if your query includes the trailing '/' then it means an exact match vs any
descendent. We could add this trailing '/' in the URP, though it feels more
like this addition belongs elsewhere since we don't need this trailing '/' in
the stored form which is what would happen. Still; not a big deal if we do it
in the URP -- just one char. With this change, your query would look like
this:
{noformat}
-_NEST_PATH_:"toppings/" +_NEST_PATH_:"toppings"
{noformat}
This query assumes "toppings" is a top level child. If we need any depth then
both can be wildcards with a leading '*' (actually more complicated to
differentiate a "stoppings" from "toppings").
I feel like a lot of this sort of logic could go into a new FieldType. The
FieldType would be responsible for encapsulating the analysis indexing
config/logic, and thus it becomes a one-liner in anyone's schema. More
importantly, it could encapsulate simple query parsing rules and accept some
local-param options. So imagine something like this:
Find any comment element: (not necessarily at root)
{noformat}
{!field f=myPathField}comment
{noformat}
Find the comments at this path: (this example is a comment of a comment of the
top doc)
{noformat}
{!field f=myPathField}/comment/comment
{noformat}
Find the comments at this path and all descendants:
{noformat}
{!field f=myPathField descendants=true}/comment/comment
{noformat}
Find the comments at this path and all descendants but not itself:
{noformat}
{!field f=myPathField self=false descendants=true}/comment/comment
{noformat}
Find the comments at this path and all ancestors:
{noformat}
{!field f=myPathField ancestors=true}/comment/comment
{noformat}
This is possible because a FieldType implements getFieldQuery with the QParser
passed in exposing local params. Most spatial fields use this technique to
e.g. pass distErrPct in the query.
> Support Deeply Nested Docs In Child Documents Transformer
> ---------------------------------------------------------
>
> Key: SOLR-12519
> URL: https://issues.apache.org/jira/browse/SOLR-12519
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: mosh
> Priority: Major
>
> As discussed in SOLR-12298, to make use of the meta-data fields in
> SOLR-12441, there needs to be a smarter child document transformer, which
> provides the ability to rebuild the original nested documents' structure.
> In addition, I also propose the transformer will also have the ability to
> bring only some of the original hierarchy, to prevent unnecessary block join
> queries. e.g.
> {code} {"a": "b", "c": [ {"e": "f"}, {"e": "g"} , {"h": "i"} ]} {code}
> Incase my query is for all the children of "a:b", which contain the key "e"
> in them, the query will be broken in to two parts:
> 1. The parent query "a:b"
> 2. The child query "e:*".
> If the only children flag is on, the transformer will return the following
> documents:
> {code}[ {"e": "f"}, {"e": "g"} ]{code}
> In case the flag was not turned on(perhaps the default state), the whole
> document hierarchy will be returned, containing only the matching children:
> {code}{"a": "b", "c": [ {"e": "f"}, {"e": "g"} ]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
