lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-5285) Solr response format should support child Docs
Date Wed, 21 May 2014 22:50:38 GMT

    [ 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.
> [~hossman_lucene@fucit.org] 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message