[
https://issues.apache.org/jira/browse/LUCENE-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179503#comment-13179503
]
Yonik Seeley commented on LUCENE-3672:
--------------------------------------
Generation isn't as good as version for telling if something has changed - it's
much easier (probably trivial) to get a false match under real usage scenarios.
> IndexCommit.equals() bug
> ------------------------
>
> Key: LUCENE-3672
> URL: https://issues.apache.org/jira/browse/LUCENE-3672
> Project: Lucene - Java
> Issue Type: Bug
> Components: core/index
> Affects Versions: 4.0
> Reporter: Andrzej Bialecki
>
> IndexCommit.equals() checks for equality of Directories and versions, but it
> doesn't check IMHO the more important generation numbers. It looks like
> commits are really identified by a combination of directory and segments_XXX,
> which means the generation number, because that's what the
> DirectoryReader.open() checks for.
> This bug leads to an unexpected behavior when the only change to be committed
> is in userData - we get two commits then that are declared equal, they have
> the same version but they have different generation numbers. I have no idea
> how this situation is treated in a few dozen references to
> IndexCommit.equals() across Lucene...
> On the surface the fix is trivial - either add the gen number to equals(), or
> use gen number instead of version. However, it's puzzling why these two would
> ever get out of sync??? and if they are always supposed to be in sync then
> maybe we don't need both of them at all, maybe just generation or version is
> sufficient?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
