lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Caching of BitSets from filters and Query.equals()
Date Tue, 06 Mar 2007 13:09:31 GMT

On Mar 6, 2007, at 6:35 AM, Antony Bowesman wrote:
> Erik Hatcher wrote:
>> Have a look at the CachingWrappingFilter:
>>     < 
>> search/CachingWrapperFilter.html> It caches filters by IndexReader  
>> instance.
> Doesn't that still have the same issue in terms of equality of  
> conditions that created the filter.  If I have conditions that  
> filter Term X, then the cached Filter is only valid for new  
> requests for Term X.  Term equality is defined by the Javadocs as  
> having the same Field and Text, but to cache a Query, its equality  
> must be deterministic in a similar way, but it isn't.

A Query's equality is defined as having the same structure and order  
as another Query.

> I was hoping that Query.equals() would be defined so that equality  
> would be based on the results that Query generates for a given reader.

That is certainly not the case, as stated above.  query1.equals 
(query2) when all the nested clauses also report back they  
are .equals one another.  This is very important in our unit tests -  
to construct a query through the QueryParser and then through the API  
and compare them.

> I'm hosting an indexing framework, so I've no idea what searches or  
> filters a caller will want to perform.

Have a look at Solr's caching mechanisms for filters, queries, and  
documents.  Very slick and scalable stuff.


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

View raw message