: I think this is a legitimate request. Majority of the similarities are : compatible index wise. I think the only exception is sweet spot : similarity.
I think you are grossly underestimating the risk of arbitrarily using diff Similarities between index time and query time -- particulaly in how norms are computed. But for the sake of argument let's assuming you know what you are doing, you are careful, and you know that the index time similarity you used is compatibly with N diff query time similarities you want to choose between... : I wonder what solr-plugin would be best for this functionality. : How about a custom search component, in its prepare method? : : I think we can access (Solr)IndexSearcher inside a SearchComponent. : setSimilarity in the process method should work. this owuld be *very* dangerous to do, because the SolrIndexSearcher is shared across all requests -- so you'd get race conditions and non-deterministic behavior from diff queries not getting the similarity they expected. The only sane way to do this on a per-request basis would either be... 1) wrap the IndexSearcher in a new IndexSearcherWrapper that returned a per-request Similarity. 2) modify the Query objects themselves so that createWeight use the similarity you want instead of delegating to INdexSearcher.getSimilarity (see for example how BooleanQuery/BooleanWeight use the "disableCoord" property of the query to decide wether or not to care about Similarity.coord Depending on your real world usecase / goal, i would suspect that either way a QParser that wraps the constructed query is going to be the simplest/cleanest solution regardless of wether #1 or #2 makes the most sense -- perhaps even achieving #2 by using #1 so that createWeight in your new QueryWrapper class does the IndexSearcher wrapping before delegating. -Hoss http://www.lucidworks.com/
