[
https://issues.apache.org/jira/browse/SOLR-14687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18064986#comment-18064986
]
David Smiley commented on SOLR-14687:
-------------------------------------
Based on use-cases I see at work, I could see it being useful for an additional
optional param to customize the nest path filter for the child doc criteria
when using parent QParser.
{noformat}
{!parent parentPath="/a/b/c" childPath="sku"}color:red
{noformat}
Without {{{}childPath{}}}, the child criteria is *any* descendant child of
/a/b/c (e.g. /a/b/c/manual), but with {{{}childPath{}}}, it's going to be
exactly "/a/b/c/sku" so the child path type is chosen specifically. It's just
concatenated to parentPath, overriding the prefix query that wold be used when
there is no childPath. Without this, you'd need to add an additional term
filter but I think it's cleaner to have this built-in so the user isn't exposed
to using {{_nest_path_}} directly. And it's faster too, of course – removes a
prefix query.
> Make child/parent query parsers natively aware of _nest_path_
> -------------------------------------------------------------
>
> Key: SOLR-14687
> URL: https://issues.apache.org/jira/browse/SOLR-14687
> Project: Solr
> Issue Type: Sub-task
> Reporter: Chris M. Hostetter
> Assignee: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A long standing pain point of the parent/child QParsers is the "all parents"
> bitmask/filter specified via the "which" and "of" params (respectively).
> This is particularly tricky/painful to "get right" when dealing with
> multi-level nested documents...
> *
> https://issues.apache.org/jira/browse/SOLR-14383?focusedCommentId=17166339&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17166339
> *
> [https://lists.apache.org/thread.html/r7633a366dd76e7ce9d98e6b9f2a65da8af8240e846f789d938c8113f%40%3Csolr-user.lucene.apache.org%3E]
> ...and it's *really* hard to get right when the nested structure isn't 100%
> consistent among all docs:
> * collections that mix docs w/o children and docs that have children.
> ** Ex: blog posts, some of which have child docs that are "comments", but
> some don't
> * when some "types" of documents can exist at multiple levels:
> ** Ex: top level "product" documents, which may have 2 types of children:
> "skus" and "manuals", but "skus" may also have their own wku-specific child
> "manuals"
> BUT! ... now that we have some semi-native support for the {{_nest_path_}}
> field, i think it may be possible to offer an "easier to use" variant syntax
> of the parent/child QParsers that directly depends on these fields. This new
> syntax should be optional – and purely syntactic sugar. "expert" users should
> be able to do all the same things using the existing syntax (possibly more
> efficiently depending on what invarients exist in their data model)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
