[
https://issues.apache.org/jira/browse/LUCENE-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-2805:
------------------------------------
Attachment: LUCENE-2805.patch
next iteration - I simplified nrtIsCurrent which is nice and all tests pass.
Yet, I couldn't get any test failing with this version
{code}
synchronized boolean nrtIsCurrent(SegmentInfos infos) {
return segmentInfos.version == infos.version;
}
{code}
so I added another test that crashes immediately if we don't check the
docWriter for changes. I also added a changes entry to runtime behavior section
since the version number are different to previos versions.
I also had to update an assert in TestIndexWriterReader#testAddIndexes since we
now don't increment the version on a commit if there are no changes but
generation might have been changed though.
I think we are good to go.
> SegmentInfos shouldn't blindly increment version on commit
> ----------------------------------------------------------
>
> Key: LUCENE-2805
> URL: https://issues.apache.org/jira/browse/LUCENE-2805
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Reporter: Michael McCandless
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2805.patch, LUCENE-2805.patch, LUCENE-2805.patch
>
>
> SegmentInfos currently increments version on the assumption that there are
> always changes.
> But, both DirReader and IW are more careful about tracking whether there are
> changes. DirReader has hasChanges and IW has changeCount. I think these
> classes should notify the SIS when there are in fact changes; this will fix
> the case Simon hit on fixing LUCENE-2082 when the NRT reader thought there
> were changes, but in fact there weren't because IW simply committed the exact
> SIS it already had.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
