lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: Caching of BitSets from filters and Query.equals()
Date Tue, 06 Mar 2007 19:52:16 GMT

: 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 ... 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).

if you think about it, there's no possible way it ever could, because a
critical piece of information isn't available when testing the
.equals()ness of those queries: the indexreader.  if i have a completley
empty index then the queries "foo:bar" and "yak:wak"will both have the
exact same results, but those same queries on an index with a single
document added might now generate different results -- so how could an
algorithm like you describe possibly be implemented in a Query.equals()
method when the IndexReader isn't known?

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
.. wether or not it results in the same set of docs as a completley
unrelated query doesn't really tell you much (i suppose you could save
some space by reusing the same BitSet object ... but that can be done by
testing hte equality of hte resulting BitSet)




-Hoss


---------------------------------------------------------------------
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