[
https://issues.apache.org/jira/browse/SOLR-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588354#comment-16588354
]
David Smiley commented on SOLR-12519:
-------------------------------------
Yetus thought the patch should be applied to the branch of the same name as
this feature, but the patch is actually for master, and so it failed. I just
deleted the branch. I ran the full test suite + precommit and found these
failures in SolrJ:
{noformat}
[junit4] Tests with failures [seed: D1E2EA5B85C1A1D2]:
[junit4] -
org.apache.solr.client.solrj.SolrExampleBinaryTest.testChildDoctransformer
[junit4] -
org.apache.solr.client.solrj.SolrExampleXMLTest.testChildDoctransformer
[junit4] -
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest.testChildDoctransformer
[junit4] -
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest.testChildDoctransformer{noformat}
Can you investigate [~moshebla]?
Separately, I wonder if it's a big deal to change the semantics of "limit" in a
minor release. AFAIK [~hossman] 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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
