[
https://issues.apache.org/jira/browse/SOLR-11517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16215476#comment-16215476
]
ananthesh commented on SOLR-11517:
----------------------------------
That is a strong hypothesis Ishan, But let's relook into my observation
again(as per the description). The child document has one set of consecutive
`_docid_` while only the parent `_docid_` was different. This means the parent
document has moved to the different segment. (I haven't analyzed the Lucene
segment, I can do it if you insist as I have the snapshot of the index for the
above issue). What could be explaining that?
> ToParentBlockJoinQuery fails when the parents/child fall in to different
> segments
> ---------------------------------------------------------------------------------
>
> Key: SOLR-11517
> URL: https://issues.apache.org/jira/browse/SOLR-11517
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.6.1
> Reporter: ananthesh
>
> We have a system where all the documents in the collections are nested child
> documents. We also have 'autoCommit' enabled for the collection. We also get
> huge number of document updates. We found a scenario, where 'child' documents
> were indexed in one segment, while 'parent' document got indexed in the other
> segment. Here are the docid looks like
> 0 = 95638
> 1 = 95639
> 2 = 95640
> 3 = 272190 \{parent}
> Now if the solr request has been made using "parent" query parser like the
> following
> {noformat}
> {!parent which=parent:true score=max}(...)
> {noformat}
> ToParentBlockJoinQuery which handles the request wont be able to find the
> parent for the searched child documents. But if we trigger `optimize` for the
> same index which forces to merge all the segments to single index, the above
> request will be able to fetch the results.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
