Hi Hoss, Thanks for sharing the knowledge on dangerous zones, will try to avoid them. #2 is quite probable way of implementing this in my case, as many Query objects are custom (although not all). But #1 is compelling too and sounds like a bit less trouble.
On Tue, Dec 15, 2015 at 8:13 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : 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/ > -- Dmitry Kan Luke Toolbox: http://github.com/DmitryKey/luke Blog: http://dmitrykan.blogspot.com Twitter: http://twitter.com/dmitrykan SemanticAnalyzer: www.semanticanalyzer.info
