lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: Issue upgrading from lucene 2.3.2 to 2.4 (moving from bitset to docidset)
Date Tue, 09 Dec 2008 07:36:00 GMT

The change from BitSet to DocIdSetIterator implies that you'll
need to choose an underlying data structure yourself.

A minimal approach would be to use DocIdBitSet around
BitSet, but there are better ways.

For your application you might consider to replace java's BitSet by
lucene's OpenBitSet. Also have a look at earlier discussions
on the subject: you might find a good use for OpenBitSetDISI and 

Paul Elschot

Op Tuesday 09 December 2008 07:44:20 schreef Michael Stoppelman:
> Hi all,
> I'm working on upgrading to Lucene 2.4.0 from 2.3.2 and was trying to
> integrate the new DodIdSet changes since
> method is now depreciated. For our app we actually heavily rely on
> bits from the Filter to do post-query filtering (I explain why
> below).
> For example, if someone searches for product: "ipod" and then filters
> a type: "nano" (e.g. mini/nano/regular) AND color: "red" (e.g.
> red/yellow/blue). In our current model the results are gathered in
> the following way:
> 1) "ipod" w/o attributes is run and the results are stored in a
> hitcollector 2) "ipod" results are now filtered for color="red" AND
> type="mini" using the lucene Filters
> 3) The filtered results are returned to the user.
> The reason that the attributes are filtered post-query is so that we
> can return the other types and colors the user can filter by in the
> future. Meaning the UI would be able to show "blue", "green", "pink",
> etc... if we pre-filtered results by color and type before hand we
> wouldn't know what the other filter options would be there for a
> broader result set.
> Does anyone else have this use case? I'd imagine other folks are
> probably doing similar things to accomplish this.
> M

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message