lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <cutt...@apache.org>
Subject Re: SweetSpotSimiliarity
Date Wed, 24 May 2006 19:49:47 GMT
Marvin Humphrey wrote:
> Searcher.getSimilarity() is documented as a public method, but maybe  
> it's still OK to add Searcher.getSimilarity(String field)

Right.  We can add a new method that, by default, punts to the old method.

> and change  
> over the various Query subclasses to request it via a new  
> Query.getSimilarity(Searcher searcher, String Field) method.

I don't see the need for the latter.  TermQuery.getSimilarity(Searcher) 
could simply call Searcher.getSimilarity(String field), no?

> That would work for TermQuery and PhraseQuery, as they're both  limited 
> to a single field.  Assessing whether it would work for  BooleanQuery is 
> confusing.  Various clauses in BooleanQuery can have  different fields.  
> The main concern I have is that each subquery not  have an incorrect 
> Similarity instance imposed on it from above by the  parent BooleanQuery.

I don't follow.  BooleanQuery doesn't call tf(), so its okay if it still 
calls Searcher.getSimilarity(), right?

Doug

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


Mime
View raw message