One of the primary reasons that I was doing it this way is because I am sending several filters, one is a big docset and others are BooleanQuery objects (products in stock, etc.).
Since, the interface for SolrIndexSearcher.getDocListAndSet supports only (Query, DocSet,...) or (Query, List<Query>,...), I was going to give it a list of filters. I haven't investigated further to see if patching the Solr code to allow both methods (Query, List<Query>, DocSet) would cause any problems. My guess is that it was done this way for a reason. Barring that solution, I will probably use the Query, DocSet method. I have my DocSet for my bit-based filters in a single DocSet. And then I can take my previous list of filter queries and add them onto the main Query object that was created by the front-end. I'm not sure what this will do to cache performance though. Since, now each variation in the filter queries will become an entirely different query for the cache. ----- Original Message ---- From: Chris Hostetter <[EMAIL PROTECTED]> To: Solr <solr-user@lucene.apache.org> Sent: Tuesday, May 20, 2008 12:00:59 PM Subject: Re: DocSet to BitSet : I have a custom query object that extends ContstantScoreQuery. I give it : a key which pulls some documents out of a cache. Thinking to make it : more efficient, I used DocSet, backed by OpenBitSet or OpenHashSet. : However, I need to set the BitSet object for the Lucene filter. Any idea : on how to best do this from DocSet? It seems like this is a problem that : people have encountered before. I've never really encountered this particular problem ... typically any "sets" i'm dealing with can be passed as "filters" directly to the SolrIndexSearcher method -- so I use DocSets. if I *had* to use a ConstantScoreQuery, i'd probably skip DocSet initially and use a BitSet from the get go (the BitSets could still be cashed using custom cache). but you could also just create anew custom constnat scoring Query class that used a Scorer that refrenced your DocSet directly. if you look at the source of ConstantScoreQuery it should be fairly obvious how to make something similar backed by a DocSet instead of a Filter. (in future versions of Lucene this will all be moot, as the Filter API will no longer require a BitSet and can intead return a "DocIdSet" which is essentially just an iterator that Solr's DocSet can implement trivially. ... if you look at the trunk version of ConstantScoreQuery it already does this ... that class may serve as an even better example of implementing a Query that scores based on an o.a.s.search.DocIterator) -Hoss
