lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Updated] (LUCENE-3084) MergePolicy.OneMerge.segments should be List<SegmentInfo> not SegmentInfos
Date Wed, 11 May 2011 21:29:47 GMT


Uwe Schindler updated LUCENE-3084:

    Attachment: LUCENE-3084-trunk-only.patch

Different patch idea:
- OneMerge clones the list, so all MergePolicys don't need to take care, that the list may
change later (e.g. is it's based on SegmentInfos.subList() which changes later during merge)
- Removed SIs.range() completely

* Speaking logically, merges operate on Sets of SIs, not List?
* Let's stop subclassing random things? : ) SIS can contain a List of SIs (and maybe a Set,
or whatever we need in the future), and only expose operations its clients really need.

Merges are ordered, so it must be an ordered Set like LinkedHashSet.

SegmentInfos itsself must be list, as the segments of an index are ordered.

All tests pass with this patch.

The cloning should also be moved to OneMerge in 3.x. range() should simply delegate to subList
(and no longer clone).

> MergePolicy.OneMerge.segments should be List<SegmentInfo> not SegmentInfos
> --------------------------------------------------------------------------
>                 Key: LUCENE-3084
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 3.2, 4.0
>         Attachments: LUCENE-3084-trunk-only.patch, LUCENE-3084-trunk-only.patch, LUCENE-3084.patch
> SegmentInfos carries a bunch of fields beyond the list of SI, but for merging purposes
these fields are unused.
> We should cutover to List<SI> instead.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message