[
https://issues.apache.org/jira/browse/SOLR-10114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868667#comment-15868667
]
Yonik Seeley commented on SOLR-10114:
-------------------------------------
bq. On the other hand, addAndDelete() did not do any differentiation for block
docs
Nice catch! Looks like that oversight has been there since the original
block-join patch.
bq. AFAIK, the reordering cannot happen on the leader, this does not affects
leader version, only replicas. I assume any peersync would fail due to
fingerprint check, and would eventually replicate the correct index.
Yeah, sounds right.
> child documents lack _version_, susceptible to reordered delete-by-query
> -------------------------------------------------------------------------
>
> Key: SOLR-10114
> URL: https://issues.apache.org/jira/browse/SOLR-10114
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Yonik Seeley
> Attachments: SOLR-10114.patch, SOLR-10114.patch,
> SOLR-10114-validation.patch
>
>
> It looks like when a block of documents is indexed, child documents get no
> \_version\_ field. This means (among other potential issues) that a
> delete-by-query that is reordered will cause matching child documents to be
> deleted. DBQ normally prevents deleting newer docs by including a
> restriction on \_version\_, which doesn't work for anything lacking that
> field. Re-ordered delete-by-term of any child docs would also be affected
> (although it should be a much rarer issue.)
> The leading candidate for a fix is to use the exact same \_version\_ for all
> child docs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
