On May 24, 2006, at 12:49 PM, Doug Cutting wrote:
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?
Yes, that'd work.
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?
I think I agree.
I'm imagining that there would be some API along the lines of
setSimilarity(String field, Similarity sim) at the Searcher level.
What I'm worried about is that some parent would have its Similarity
instance determined by Query.getSimilarity(Searcher searcher) and
that it would then lose track of the override that was performed at
the Searcher level and supply the wrong Similarity to a child.
Not being familiar with all of the Query classes and how they expand
into Scorers, I feel like I have to go spelunk all of them to make
sure that no Query ever propagates its Similarity instance to a child
in such a way. Making the broad statement that all instances of
Query.getSimilarity(Searcher searcher) should be replaced with
Query.getSimilarity(Searcher searcher, String fieldName) was easier.
It saved me from having to do the spelunking now, by imposing the
requirement that we'd have to do that spelunking later.
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
