[
https://issues.apache.org/jira/browse/SOLR-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589155#comment-16589155
]
Hoss Man commented on SOLR-12519:
---------------------------------
bq. AFAIK Hoss Man you originally added the ChildDocTransformer and implemented
"limit" as starting from the furthest child document from the root. I think
that's an odd choice. Wouldn't the "top" of the of child docs be closest to the
root document; wouldn't that be more useful? I suspect that most users don't
actually want to limit child docs so configure it not to limit... but I don't
know for sure, that's just my hunch.
I'm not really following what you mean, the code doesn't go out of it's way to
try and get the "top" children or the bottom children -- it just executes a
ToChildBlockJoinQuery (fltered by the childFilterQuery) and let's the docs be
returned in the score order of that query w/a limit on the qunaiy -- perhaps
you're refering to the sort by score? does ToChildBlockJoinQuery score the
"farthest" queries higher for some reason?
i don't think we've ever documented how the limit was applied, so i don't think
it's a huge problem to change it ... but it would also probably be trivial to
add a "sort" local param to that transformer if you were worried about giving
affected users an easy way to force the olde behavior.
IIRC that limit is largely as a safety valve to prevent massive responses, i
doubt anyone would be too affecte by the order changing.
as far as i can understad from looking at the existing code it doesn't really
go out of its way to choose which child docs are returned -- it's
> 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
> Attachments: SOLR-12519-no-commit.patch, SOLR-12519.patch
>
> Time Spent: 23h 10m
> Remaining Estimate: 0h
>
> 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
