Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41DDAA3E.20408@apache.org>
Date: Thu, 06 Jan 2005 13:14:38 -0800
From: Doug Cutting <cutting@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041127)
MIME-Version: 1.0
To: Lucene Developers List <lucene-dev@jakarta.apache.org>
Subject: Re: DO NOT REPLY [Bug 32965]  -    Use filter bits for next() and
 skipTo() in FilteredQuery
References: <200501061913.j06JDUoR018522@ajax.apache.org>
In-Reply-To: <200501061913.j06JDUoR018522@ajax.apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

bugzilla@apache.org wrote:
> ------- Additional Comments From paul.elschot@xs4all.nl  2005-01-06 20:13 -------
> Patch to IndexSearcher.java to use FilteredQuery

I like where this is going, and want to take it further!

Why not patch Searcher.java instead of IndexSearcher.java?  Once that's 
done, Filters could be removed from the Searchable interface and only 
appear (for back-compatibility and/or convenience) in Searcher utility 
methods.

This would simplify auto-filtering.  Instead of a Query -> Query+Filter 
transformation, we could just use a Query -> Query transformation.  For 
example, the rewrite method on BooleanQuery could look for clauses which 
are somehow declared non-scoring (e.g., boost=0) and, when these exist, 
rewrite itself as a FilteredQuery, constructing a Filter for all of the 
non-scoring clauses.

There's still the issue of caching filters.  This might be as simple as:
(a) combine the caches used by QueryFilter and CachingWrappingFilter;
(b) implement the unified cache as an LRU, possibly taking into account 
different filter sizes, etc.
(c) add a Query.getFilterBits(IndexReader, DocIdCollector)  method 
that's implemented with a Scorer by default, but which may be optimized, 
e.g., for RangeQuery, TermQuery, etc.
(d) write a BooleanQueryFilter implementation that uses 
Query.getFilterBits() to combine a number of clauses into a single 
bit-vector that can be cached.

Does this make any sense?

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org