[
https://issues.apache.org/jira/browse/SOLR-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-8271.
----------------------------
Resolution: Fixed
Assignee: Hoss Man
Fix Version/s: Trunk
> use SchemaSimilarityFactory as default when no explicit (top level) sim is
> configured
> -------------------------------------------------------------------------------------
>
> Key: SOLR-8271
> URL: https://issues.apache.org/jira/browse/SOLR-8271
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8271.patch, SOLR-8271.patch
>
>
> Idea spun out of SOLR-8057...
> bq. 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)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
