[
https://issues.apache.org/jira/browse/SOLR-14963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17223091#comment-17223091
]
Alexandre Rafalovitch commented on SOLR-14963:
----------------------------------------------
When I dug into original discussion, my feeling was that it was centered around
shallow tree, so a parent document with a bunch of children. So, the use cases
with grand-parents and so on were not necessarily flushed out. Which, combined
with breadth-first iteration internally (IIRC) caused the current setup to be
super confusing.
I think the limit should be per parent/child relationship (per level could
still mean shared between X parents at level 1). So, If we imagine each parent
at every level having 10 children (10^depth total nodes) and we said rows=3, we
would get 3^depth returned. Currently, I think, if we said limit=25, we would
get 10 top level nodes, 10 children of the first node, and 5 children of the
second node and nothing for other 8 without any indication. And basically what
I hit originally.
I am ok with default being unlimited. Then, if they are hit with super-deep and
wide trees, they can use this parameter explicitly.
> Child "rows" param should apply per level
> -----------------------------------------
>
> Key: SOLR-14963
> URL: https://issues.apache.org/jira/browse/SOLR-14963
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Major
>
> The {{[child rows=10]}} doc transformer "rows" param _should_ apply per
> parent, and it's documented this way: "The maximum number of child documents
> to be returned per parent document.". However, it is instead implemented as
> an overall limit as the child documents are processed in a depth-first order
> way. The implementation ought to change.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
