Christoph Goller wrote: [...]
I also think this is the best way to fix this bug. However there may be a
way to implement this while avoiding to change the Weight and Searchable
API. The idea is to rewrite the query in MultiSearcher and while rewriting
compile the global idf into the query boosts. For this step calls to all Searchables are needed and the optimization already in this thread is
applicable. The search methods in Searchables then have to be told to not
use their local idf during search. This could e.g. be made by giving them
a special Similarity. It should be a subclass of the similarity specified for
the current search with idf() always returning 1. Similarity would have to be
serializable and Query would have to contain a member of type similarity.
Query´s getSimilarity(Searcher) could be implement to either return Searcher´s
Similarity or Query´s private similarity if not null.
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.
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
