[
https://issues.apache.org/jira/browse/LUCENE-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15881076#comment-15881076
]
Simon Willnauer commented on LUCENE-7707:
-----------------------------------------
bq. Maybe we could require that either all incoming shardIndex are undefined,
or all are set, but you are not allowed to mix?
I think this is what we should ultimately do. I don't see a different way than
peaking at the at the TopDocs so see if it's preset and then executed based on
that. I can certainly add assertions...
> Only assign ScoreDoc#shardIndex if it was already assigned to non default
> (-1) value
> ------------------------------------------------------------------------------------
>
> Key: LUCENE-7707
> URL: https://issues.apache.org/jira/browse/LUCENE-7707
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Simon Willnauer
> Fix For: master (7.0), 6.5.0
>
> Attachments: LUCENE-7707.patch, LUCENE-7707.patch
>
>
> When you use TopDocs.merge today it always overrides the ScoreDoc#shardIndex
> value. The assumption that is made here is that all shard results are merges
> at once which is not necessarily the case. If for instance incremental merge
> phases are applied the shard index doesn't correspond to the index in the
> outer TopDocs array. To make this a backwards compatible but yet
> non-controversial change we could change the internals of TopDocs#merge to
> only assign this value unless it's not been assigned before to a non-default
> (-1) value to allow multiple or sparse top docs merging.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
