On 5/12/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
> So the first step is to decide if we should migrate to this, and if
> so, where it belongs.
> - lucene.util? BitSet is hard-coded into Lucene in enough places that
> I don't know if it would be useful to people there or not.
> - solr.util?
>
> The next step would be to actually use it... replacing BitSet with
> OpenBitSet in BitDocSet (an alternative would be to create another
> DocSet type, but that gets more complicated).
Shouldn't we really replace BitSet in Lucene with an interface that
OpenBitSet & others implement?
It depends on what the goal is and what the interface would cover.
It would useful to have very restrictive small interfaces that do
specific things, and implementations of these interfaces can wrap
different underlying data structures.
For example, there's DocNrSkipper for filtering a query:
http://issues.apache.org/jira/browse/LUCENE-328
BitSetSortedIntList wraps a BitSet and implements DocNrSkipper.
We could also have an interface for the creation side...
SequentialIntListCreator where ids must be added in order,
or RandomAccessIntListCreator where ids may be added in any order.
But I don't see OpenBitSet implementing any of these interfaces
directly, but instead being used as an underlying store for certain
implementations.
Did you have something else in mind?
This has been raised many times, that
Filters should return something that implements an interface, not a
BitSet.
+1 on that...
Doing this back-compatibly will be a bit of a pain, but I think
the effort is warranted.
Disallowing the non-skipping BooleanScorer would allow use of SkipFilters.
-Yonik
