lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Bowesman <...@teamware.com>
Subject Re: Caching of BitSets from filters and Query.equals()
Date Tue, 06 Mar 2007 20:22:41 GMT
Chris Hostetter wrote:
> : 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.
> 
> if query1.equals(query2) then the results of query1 on an
> indexreader should be identical to the results of query2 on the same
> indexreader 

Thanks Hoss and Erik.  This is the case I wanted, but re-reading my desire 
above, I see it looks more like the inverse.  Sorry for the confusion.

> ... but there inverse can not be garunteed: if query1 and
> query2 generate identical results when queried against an indexreader that
> says absolutely nothing about wether query1.equals(query2).

Yes, that's not what I was after - As you say, it's not possible to implement.

> in general, what you describe really isn't needed for caching query result
> sets ... what matters is that if you've already seen the query before
> (which you can tell using q1.equals(q2)) then you don't need to execute it

Exactly, and to be sure of that you have to be able to rely on an overridden 
equals to get q1.equals(q2).  The core Lucene Query implementations do override 
equals() to satisfy that test, but some of the contrib Query implementations do 
not override equals, so you would never see the same Query twice and caching 
BitSets for those Query instances would be a waste of time.

Antony





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


Mime
View raw message