[
https://issues.apache.org/jira/browse/LUCENE-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195604#comment-13195604
]
Uwe Schindler commented on LUCENE-3661:
---------------------------------------
One thing: Can we not split the BitVector and LiveDocs in 3.x and trunk? Just
because the logic is inverse in 3.x (deletions instead of live docs). This
would also make the LiveDocs in trunk always have a codec header, but not in
3.x?
Otherwise, looks great!
> move deletes under codec
> ------------------------
>
> Key: LUCENE-3661
> URL: https://issues.apache.org/jira/browse/LUCENE-3661
> Project: Lucene - Java
> Issue Type: Task
> Affects Versions: 4.0
> Reporter: Robert Muir
> Attachments: LUCENE-3661.patch
>
>
> After LUCENE-3631, this should be easier I think.
> I haven't looked at it much myself but i'll play around a bit, but at a
> glance:
> * SegmentReader to have Bits liveDocs instead of BitVector
> * address the TODO in the IW-using ctors so that SegmentReader doesn't take a
> parent but just an existing core.
> * we need some type of minimal "MutableBits" or similar subinterface of bits.
> BitVector and maybe Fixed/OpenBitSet could implement it
> * BitVector becomes an impl detail and moves to codec (maybe we have a shared
> base class and split the 3.x/4.x up rather than the conditional backwards)
> * I think the invertAll should not be used by IndexWriter, instead we define
> the codec interface to say "give me a new MutableBits, by default all are
> set" ?
> * redundant internally-consistent checks in checkLiveCounts should be done in
> the codec impl instead of in SegmentReader.
> * plain text impl in SimpleText.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]
