[jira] [Comment Edited] (SOLR-12519) Support Deeply Nested Docs In Child Documents Transformer

["Hoss Man (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16589155#comment-16589155 ] 

Hoss Man edited comment on SOLR-12519 at 8/22/18 5:42 PM:
----------------------------------------------------------

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.



was (Author: hossman):
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org