This is more or less how the patch I already submitted works (except that it ignored the query rewriting step). The problem I see with this now is that if I (ab-)use the Similarity class for idf transmission, it can't be redefined anymore by a user who wants to use a custom Similarity measure.
My intention was to (ab-)use query boosts for idf transmission and to
overwrite Similarity so that local idf is ignored. The idea was to
simply multiply global idf into the given boost. Unfortunately idf is
not only used with the boosts and query normalization. It also occurs
in the document part of the scoring algorithm. If you look into TermWeight.normalize(float queryNorm) there is an additional
multiplication with idf. The same holds for PhraseWeight. So my idea
probably does not work :-(
But there is still the valid question why the Similarity is owned by the Searchables and not by the query. For me it seems to be more logical that the Similarity measure used should be part of the query, but of course there may be good reasons why this is not the case currently. Probably the discussion is moot anyway, because I guess that about 99% Lucene-based applications use the default Similarity.
Searchables currently don´t have a Similarity, Searchers do. By overwriting Query.getSimilarity(Searcher) a Query may have its own Similarity. Maybe Query should get a private member variable Similarity that is null by default and getter/setters. If this variable is set explicitly Query.getSimilarity(Searcher) could return Query´s Similarity, otherwise the Searcher´s similarity. This looks reasonable to me. I think you had that kind of variable already.
Christoph
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
