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.
M On Tue, Dec 9, 2008 at 1:47 AM, Michael McCandless < [EMAIL PROTECTED]> 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 o.a.l.search.Filter#bits() 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
