[
https://issues.apache.org/jira/browse/LUCENE-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664083#action_12664083
]
Michael McCandless commented on LUCENE-1476:
--------------------------------------------
I think it's fine to expose this API, mark it expert & subject to
change, and state that it simply returns the current deleted docs
BitVector and any synchronization issues must be handled by the app.
Probably it should be package private or protected.
Also, I think Multi*Reader would not implement this API? Meaning
you must get the individual SegmentReader and ask it.
Since we are discussing possible changes to deleted docs, eg switching
to iterator-only accesss, maybe applying deletions as a filter, maybe
using "tombstones" under-the-hood, etc., this API could very well
change.
For our current thinking on realtime search, I think one weak part of
the design is the blocking copy-on-write required for the first
deletion on a newly cloned reader. The time taken is in proportion to
the size of the segment. Switching to a design that can background
this copy-on-write will necessarily impact how we represent
and access deletions.
> BitVector implement DocIdSet
> ----------------------------
>
> Key: LUCENE-1476
> URL: https://issues.apache.org/jira/browse/LUCENE-1476
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.4
> Reporter: Jason Rutherglen
> Priority: Trivial
> Attachments: LUCENE-1476.patch, quasi_iterator_deletions.diff
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> BitVector can implement DocIdSet. This is for making
> SegmentReader.deletedDocs pluggable.
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
