[
https://issues.apache.org/jira/browse/SOLR-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959412#comment-13959412
]
Hoss Man commented on SOLR-5285:
--------------------------------
Hey Varun, thanks for working on this -- great idea.
I haven't reviewed your implementation details in depth, but here's my
comments/concerns/questions based on an initial skim of your patch...
* _"There is no way to specify return fields for a childDoc. Should there be an
option?"_
** I think so, probably an "fl" option on the {{\[child\]}} transformer, but if
that's non-trivial to add right now, we should at least clearly document/test
that all of the child fields come back -- ie: make sure it's not inadvertently
affected by the top level 'fl' param)
* _"I added ChildDocTransformerFactory#toSolrDocument which is the same as
TextResponseWriter#toSolrDocument. It's not the best thing to do."_
** no .. we should just refactor this into a static utility method somewhere.
* it's not clear to me from the API what to expect will happen if i have more
then one level of parent-child relationships in my index -- will children &
grandchildren be returned? whatever is expected needs to be documented/tested
* This should ideally work (and be tested) when using SolrJ and JavaBin -- but
at a minimum we must ensure it doesn't cause requests to explode with weird
errors -- particularly since i notice your patch modifies
{{o.a.s.common.SolrDocument}} but i don't see any updates to the javabin codec.
** we should also ensure/test that the codec is updated in such a way that
people who don't use this feature won't get weird errors when using
old_solrj+new_solr or new_solrj+old_solr (ie: don't include an empty list of
children in the binary data if the transformer isn't used at all)
* the way you create the index in {{TestChildDocTransformer}} is pretty
confusing and seems overly convoluted -- it would be a lot more straight
forward to use real, nested, {{SolrInputDocuments}} and something like
{{SolrTestCaseJ4.addAndGetVersion}}
* in ChildDocTransformer.transform, the use of {{String.format}} &
{{"\{!child..\}"}} seems like unneccessary overhead -- we should just use {{new
ToChildBlockJoinQuery(...)}}
** no need to build up a string just to parse it, and as things stand now i'm
pretty sure you'll get weird errors if parentFilter contains quotes
* It looks like there is an NPE waiting to happen in {{SolrDocument.clear()}}
> 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.8
>
> Attachments: SOLR-5285.patch, SOLR-5285.patch
>
>
> 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]
