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 same things as well.
-- Jack Krupansky On Tue, Dec 15, 2015 at 2:42 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : 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 developed this weird assumption that > switching from/to SweetSpotSimilarity in particular requires reindexing > but that many/most other Similarities wouldn't require this ... > SweetSpotSimilarity certainly has explicit config options for tuning the > index time field norm, but it's not a special case... > > 1) Solr shouldn't make any naive assumptions about whatever > arbitrary (custom) Similarity class a user might provide -- particularly > when it comes to field norms, since the all of the Similarity base classes > / callers have been setup to make it trivial for people to write custom > ismilarities for the express purpose of adjusting how many bits are used > by field norms. > > 2) In both ClassicSimilarity and BM25Similarity (the new default in Solr6) > the config option "discountOverlaps" impacts what norm values get encoded > at index time for a given field length -- so it's possible to break things > w/o even switching what class you use, w/o even consider custom Similarity > impls (or new out of the box similarity classes that might be added to > Solr tomorow) > > > -Hoss > http://www.lucidworks.com/ >
