Hi Markus,
I confirm (if that counts) that all current built-in similarities (expect Sweet
spot) save same stuff into the norms.
They can be switched/changed at search time. Actually, I am doing this today
with Lucene, experimenting different term-weighting models using a single
index. It would
There should probably be some doc notes about this stuff, at a minimum
alerting the user to the prospect that changing the similarity for a field
(or the default for all fields) can require reindexing and when it is
likely to require reindexing. The Lucene-level Javadoc should probably say
these sa
try Kan
> Sent: Tuesday 15th December 2015 19:07
> To: solr-user@lucene.apache.org; Ahmet Arslan
> Subject: Re: similarity as a parameter
>
> Markus, Jack,
>
> I think Ahmet nails it pretty nicely: the similarity functions in question
> are compatible on the index level
: Sweetspot does require reindexing but is that the only one? I have not
: investigated some exotic implementations, anyone to confirm sweetspot is
: the only one? In that case you could patch QueryComponent right, instead
: of having a custom component?
I'm not sure how where this thread deve
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
Markus, Jack,
I think Ahmet nails it pretty nicely: the similarity functions in question
are compatible on the index level. So it is not necessary to create a
separate search field.
Ahmet, I like your idea. Will take a look, thanks.
Rgds,
Dmitry
On Tue, Dec 15, 2015 at 7:58 PM, Ahmet Arslan
wr
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.
Ahmet
On Tuesday, December 15, 2015 7:43 PM, Ahmet
: 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 h
Hi Dmitry,
I think this is a legitimate request. Majority of the similarities are
compatible index wise. I think the only exception is sweet spot similarity.
In Lucene, it can be changed on the fly with a new Searcher. It should be
possible to do so in solr.
Thanks,
Ahmet
On Tuesday, Decemb
You would need to define an alternate field which copied a base field but
then had the desired alternate similarity, using SchemaSimilarityFactory.
See:
https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements
-- Jack Krupansky
On Tue, Dec 15, 2015 at 10:02 AM, Dmitry Kan wrote:
solr-user@lucene.apache.org
> Subject: similarity as a parameter
>
> Hi guys,
>
> Is there a way to alter the similarity class at runtime, with a parameter?
>
> --
> Dmitry Kan
> Luke Toolbox: http://github.com/DmitryKey/luke
> Blog: http://dmitrykan.blogspot.com
Hi guys,
Is there a way to alter the similarity class at runtime, with a parameter?
--
Dmitry Kan
Luke Toolbox: http://github.com/DmitryKey/luke
Blog: http://dmitrykan.blogspot.com
Twitter: http://twitter.com/dmitrykan
SemanticAnalyzer: www.semanticanalyzer.info
12 matches
Mail list logo
