[
https://issues.apache.org/jira/browse/SOLR-8586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15122410#comment-15122410
]
Ishan Chattopadhyaya commented on SOLR-8586:
--------------------------------------------
The approach looks good to me.
{quote}
{code}
+ // TODO: this could be parallelized, or even cached per-segment if
performance becomes an issue
{code}
{quote}
I am thinking if per-segment caching would conflict with any potential for
in-place docValues updates support (SOLR-5944)? I'm saying this based on my
assumption that docValues updates re-writes the docValues file for a previously
written segment. Given that, in such a case, version field would be a DV field,
would per-segment caching of the fingerprint need to be aware of in-place
updates within a segment (whenever that support is built)?
> Implement hash over all documents to check for shard synchronization
> --------------------------------------------------------------------
>
> Key: SOLR-8586
> URL: https://issues.apache.org/jira/browse/SOLR-8586
> Project: Solr
> Issue Type: Improvement
> Reporter: Yonik Seeley
> Attachments: SOLR-8586.patch, SOLR-8586.patch
>
>
> An order-independent hash across all of the versions in the index should
> suffice. The hash itself is pretty easy, but we need to figure out
> when/where to do this check (for example, I think PeerSync is currently used
> in multiple contexts and this check would perhaps not be appropriate for all
> PeerSync calls?)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
