lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-2805) SegmentInfos shouldn't blindly increment version on commit
Date Wed, 08 Dec 2010 09:19:00 GMT


Michael McCandless commented on LUCENE-2805:

bq.  needed to change an assert in the backwards tests so that is potentially a bw break and
I am not 100% sure how we handle this right now. Is changing the bw test ok in this case?
If its really a bw break I guess we should also list it in the BW section in CHANGES.txt

It's fine to change the test -- and the CHANGES entry already explains this?  (Though maybe
fix the CHANGES to explain that this now means some readers will in fact return "true" from
isCurrent when then before incorrectly returned "false"?).

> SegmentInfos shouldn't blindly increment version on commit
> ----------------------------------------------------------
>                 Key: LUCENE-2805
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>            Reporter: Michael McCandless
>            Assignee: Simon Willnauer
>             Fix For: 3.1, 4.0
>         Attachments: LUCENE-2805.patch, LUCENE-2805.patch, LUCENE-2805.patch, LUCENE-2805_3x.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:
For additional commands, e-mail:

View raw message