[
https://issues.apache.org/jira/browse/SOLR-12637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18085004#comment-18085004
]
Dmitry Tikhonov edited comment on SOLR-12637 at 5/31/26 4:52 PM:
-----------------------------------------------------------------
Thanks [~dsmiley] — the current {{[child]}} implementation reconstructs the
hierarchy correctly. One behavior that wasn't obvious to me from the docs: when
{{limit}} is used (e.g. {{{}[child limit=2]{}}}), the limit applies to the
{*}total number of returned descendants across the whole subtree{*}, not per
nesting level or per parent.
For a three-level parent:
{code:java}
product_1
sku_1
sub_sku_1_1
sub_sku_1_2
sub_sku_1_3
sku_2
sub_sku_2_1
... {code}
{{[child limit=2]}} returns {{sku_1}} and {{sub_sku_1_1}} — the first two
descendants in document order — and stops, rather than, say, the first two
children at each level. That was surprising at first.
{{[subquery]}} does solve this, since it gives independent
{{{}rows{}}}/{{{}sort{}}}/{{{}start{}}} per level — but at the cost of an extra
query per parent document (N+1).
Two things that I think would make {{[child]}} stronger:
# *Sorting and pagination of children* (e.g. sort variants by rating, or page
within a parent). Today children come back in document order with only a total
cap.
# *Per-parent / per-level limits* instead of a single flat limit over the
flattened subtree.
One possible direction: implement this as a SearchComponent that runs after the
main result set is collected and batch-fetches descendants for all matched
parents in a single query — e.g.
{code:java}
{!terms f=_root_ separator=||}product_1||product_2... {code}
then groups them back by _{{{}_root__{}}}. That avoids {{{}[subquery]{}}}'s N+1
(one extra query for the whole page of parents instead of one per parent) while
still allowing sort, pagination, and per-parent limits. I've prototyped
something close to this for a four-level catalog specifically to eliminate the
N+1 cost, and it worked well.
To be clear, {{[child]}} is great as-is for shallow hierarchies and small
fan-out where you're not using {{limit}} — it's only the deep-hierarchy +
{{limit}} combination where the semantics get surprising.
was (Author: squallsama):
Thanks [~dsmiley] — the current {{[child]}} implementation reconstructs the
hierarchy correctly. One behavior that wasn't obvious to me from the docs: when
{{limit}} is used (e.g. {{{}[child limit=2]{}}}), the limit applies to the
{*}total number of returned descendants across the whole subtree{*}, not per
nesting level or per parent.
For a three-level parent:
{code:java}
product_1
sku_1
sub_sku_1_1
sub_sku_1_2
sub_sku_1_3
sku_2
sub_sku_2_1
... {code}
{{[child limit=2]}} returns {{sku_1}} and {{sub_sku_1_1}} — the first two
descendants in document order — and stops, rather than, say, the first two
children at each level. That was surprising at first.
{{[subquery]}} does solve this, since it gives independent
{{{}rows{}}}/{{{}sort{}}}/{{{}start{}}} per level — but at the cost of an extra
query per parent document (N+1).
Two things that I think would make {{[child]}} stronger:
# *Sorting and pagination of children* (e.g. sort variants by rating, or page
within a parent). Today children come back in document order with only a total
cap.
# *Per-parent / per-level limits* instead of a single flat limit over the
flattened subtree.
One possible direction: implement this as a SearchComponent that runs after the
main result set is collected and batch-fetches descendants for all matched
parents in a single query — e.g. {{{!terms f=_root_
separator=||}product_1||product_2...}} — then groups them back by
{{{}_root_{}}}. That avoids {{{}[subquery]{}}}'s N+1 (one extra query for the
whole page of parents instead of one per parent) while still allowing sort,
pagination, and per-parent limits. I've prototyped something close to this for
a four-level catalog specifically to eliminate the N+1 cost, and it worked well.
To be clear, {{[child]}} is great as-is for shallow hierarchies and small
fan-out where you're not using {{limit}} — it's only the deep-hierarchy +
{{limit}} combination where the semantics get surprising.
> Return matching child documents' descendant documents using
> ChildDocTransformer
> -------------------------------------------------------------------------------
>
> Key: SOLR-12637
> URL: https://issues.apache.org/jira/browse/SOLR-12637
> Project: Solr
> Issue Type: Sub-task
> Reporter: mosh
> Priority: Major
>
> It has dawned upon me that we do not get matching children's descendant
> documents when there is a child Filter for a specific field in a child
> document query.
> I was thinking perhaps we should use the paths in the filter, rewind to the
> document proceeding the previous parent, and check each document if its path
> contains the filter. That way we can add the matching child documents
> descendants.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
