Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-8271

use SchemaSimilarityFactory as default when no explicit (top level) sim is configured

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.0
    • Component/s: None
    • Labels:


      Idea spun out of SOLR-8057...

      As far as i can tell, the chief reason SchemaSimilarityFactory wasn't made the implicit default in IndexSchema when it was introduced is because of how it differed/differs from DefaultSimilarity/ClassicSimilarity with respect to multi-clause queries – see SchemaSimilarityFactory's class javadoc notes relating to queryNorm and coord. Users were expected to think about this trade off when making a concious choice to switch from DefaultSimilarity/ClassicSimilarity to SchemaSimilarityFactory. But (again, AFAICT) these discrepencies don't exist between SchemaSimilarityFactory's PerFieldSimilarityWrapper and BM25Similiarity.

      So assuming luceneMatchVersion >= 6.0, and BM25 is implicit default, we should be able to safely switch to using SchemaSimilarityFactory as our default (which internally uses BM25 for fieldTypes that don't override) and make it much easier for people to declare fieldType overrides for the similarity (just edit the fieldType, w/o also needing to explicitly declare SchemaSimilarityFactory)


        1. SOLR-8271.patch
          4 kB
          Chris M. Hostetter
        2. SOLR-8271.patch
          13 kB
          Chris M. Hostetter

        Issue Links



            • Assignee:
              hossman Chris M. Hostetter
              hossman Chris M. Hostetter


              • Created:

                Issue deployment