lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Stoppelman" <>
Subject Re: Issue upgrading from lucene 2.3.2 to 2.4 (moving from bitset to docidset)
Date Wed, 10 Dec 2008 06:11:16 GMT
Yeah looks similar to what we've implemented for ourselves (although I
haven't looked at the implementation). We've got quite a custom version of
lucene at this point. Using Solr at this point really isn't a viable option,
but thanks for pointing this out.


On Tue, Dec 9, 2008 at 1:47 AM, Michael McCandless <> wrote:

> This use case sounds alot like faceted navigation, which Solr provides.
> Mike
> Michael Stoppelman wrote:
>  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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message