[
https://issues.apache.org/jira/browse/SOLR-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005349#comment-14005349
]
Hoss Man commented on SOLR-5285:
--------------------------------
{quote}
bq. Why is the tag name in the JSON format "childDocs" but in the XML format
it's "childDoc" (no plural) ? ... seems like those should be consistent.
I guess because in JSON the input is a JSON array hence "childDocs", while in
XML we use multiple "childDoc" tags to represent nested documents.
{quote}
That makes sense -- but now has me thinking back to the proposed usage in your
earliest comment on this issue: why create a new {{<childDoc>}} element in the
XML at all? why not just re-use {{<doc>}} (nested inside the existing
{{<doc>}}) ... that seems like the most straight forward solution, and from
what i can tell, that would probably simplify the changes to
XMLResponseParser.java as well wouldn't it?
speaking of which -- i don't understand the need for changing the method sig
for {{XMLResponseParser.readDocument}} ... why can't the method construct the
SolrDocument objects itself?
bq. Added a non mandatory parameter called "numChildDocs" which makes it
configurable. Although I'm not sure if the name is correct.
hmmm, yeah ... for consistency with the top level query we could use something
like "rows" but the risk for confusion there seems like it outweighs the
consistency factor.
how about "limit" ?
bq. Added a non mandatory parameter called "childFilter" ...
look good ... in general ChildDocTransformerFactory looks pretty good to me now
-- although I just noticed a typo in the SolrException msg if parentFilter is
null ... it refers to "which" -- but that doesn't apply here.
bq. 2. Created a new binary file for backcompatibility and forwardcompatibility.
I might be missing something, buti don't think
{{testBackCompatForSolrDocumentWithChildDocs}} is actually asserting anything
related to the child docs -- because it uses {{assertSolrDocumentEquals}}, but
that method hasn't been updated to know about child docs, has it?
----
To sum up:
* In general, i think the current patch looks great
* remaining concerns about implementation:
** {{testBackCompatForSolrDocumentWithChildDocs}} doesn't seem valid to me w/o
changes to {{assertSolrDocumentEquals}}
** err msg typo in {{ChildDocTransformerFactory}} needs fixed
** method sig change in {{XMLResponseParser.readDocument}} seems unneccesasary
* remaining questions about the API:
** better name for {{numChildDocs}} ? ... how about {{limit}} ?
** why use {{<childDoc>}} in XML instead of {{<doc>}} ?
> Solr response format should support child Docs
> ----------------------------------------------
>
> Key: SOLR-5285
> URL: https://issues.apache.org/jira/browse/SOLR-5285
> Project: Solr
> Issue Type: New Feature
> Reporter: Varun Thacker
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-5285.patch, SOLR-5285.patch, SOLR-5285.patch,
> SOLR-5285.patch, SOLR-5285.patch, SOLR-5285.patch, SOLR-5285.patch,
> SOLR-5285.patch, SOLR-5285.patch, SOLR-5285.patch, SOLR-5285.patch,
> SOLR-5285.patch, javabin_backcompat_child_docs.bin
>
>
> Solr has added support for taking childDocs as input ( only XML till now ).
> It's currently used for BlockJoinQuery.
> I feel that if a user indexes a document with child docs, even if he isn't
> using the BJQ features and is just searching which results in a hit on the
> parentDoc, it's childDocs should be returned in the response format.
> [[email protected]] on IRC suggested that the DocTransformers would
> be the place to add childDocs to the response.
> Now given a docId one needs to find out all the childDoc id's. A couple of
> approaches which I could think of are
> 1. Maintain the relation between a parentDoc and it's childDocs during
> indexing time in maybe a separate index?
> 2. Somehow emulate what happens in ToParentBlockJoinQuery.nextDoc() - Given a
> parentDoc it finds out all the childDocs but this requires a childScorer.
> Am I missing something obvious on how to find the relation between a
> parentDoc and it's childDocs because none of the above solutions for this
> look right.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
