[
https://issues.apache.org/jira/browse/LUCENE-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-3084:
----------------------------------
Attachment: LUCENE-3084-trunk-only.patch
Now I improved SegmentInfos more:
- It now uses a Map/Set to enforce that the SI only contains each segment one
time.
- Faster contains() because Set-backed
As said before: asList() and asSet() are unmodifiable, so consistency between
List and Set/Map is enforced.
The Set is itsself a Map<SI,Integer>. The values contain the index of segment
in the infos. This speeds up indexOf() calls, needed for asserts and
remove(SI). As on remove or reorder operations the indexes are no longer
correct, a separate boolean is used to mark the Map as inconsistent. It is then
regenerated on the next indexOf() call. IndexOf is seldom, butthe keySet() is
still consistent, so delaying this update is fine.
All tests pass. I think the cleanup of SegmentInfos is ready to commit.
> MergePolicy.OneMerge.segments should be List<SegmentInfo> not SegmentInfos
> --------------------------------------------------------------------------
>
> Key: LUCENE-3084
> URL: https://issues.apache.org/jira/browse/LUCENE-3084
> 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-trunk-only.patch,
> LUCENE-3084-trunk-only.patch, LUCENE-3084-trunk-only.patch,
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
