[
https://issues.apache.org/jira/browse/LUCENE-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060619#comment-13060619
]
Yonik Seeley commented on LUCENE-3280:
--------------------------------------
I think FastBitSet should still have
{code}
/** Expert: returns the long[] storing the bits */
public long[] getBits() { return bits; }
{code}
The whole reason I had to create OpenBitSet in the first place was that you
couldn't do anything custom fast (on a word-for-word basis) because the bits
were locked away from you.
> Add new bit set impl for caching filters
> ----------------------------------------
>
> Key: LUCENE-3280
> URL: https://issues.apache.org/jira/browse/LUCENE-3280
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.4, 4.0
>
> Attachments: LUCENE-3280.patch
>
>
> I think OpenBitSet is trying to satisfy too many audiences, and it's
> confusing/error-proned as a result. It has int/long variants of many
> methods. Some methods require in-bound access, others don't; of those
> others, some methods auto-grow the bits, some don't. OpenBitSet
> doesn't always know its numBits.
> I'd like to factor out a more "focused" bit set impl whose primary
> target usage is a cached Lucene Filter, ie a bit set indexed by docID
> (int, not long) whose size is known and fixed up front (backed by
> final long[]) and is always accessed in-bounds.
--
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]
