DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26716>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26716 [Patch] PerQuery Similarity Access Summary: [Patch] PerQuery Similarity Access Product: Lucene Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Search AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Here's the patch to implement the per-query Similarity access Doug described it like that : ********************************************************************* Before that, Similarity was global: there was only one implementation. I could think of cases where it might make sense to have it per-query, but that also seemed too fine-grained, so I opted to make it per-searcher. But perhaps it really *should* be possible to specify a different Similarity implementation for different queries. Here's a proposal. We add a method to Query as follows: public Query#getSimilarity(Searcher searcher) { return searcher.getSimilarity(); } Then change all of the Weight and Scorer code to call this in place of Searcher#getSimilarity(). This permits one to subclass a Query class so that it can specify it's own Similarity implementation, perhaps one that delegates through that of the Searcher. ********************************************************************* With that patch the Scorer objets are not modified because they access their own Similarity field which is specified by the Weight objects. This patch passes all junit tests --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
