[
https://issues.apache.org/jira/browse/SOLR-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-8271:
---------------------------
Attachment: SOLR-8271.patch
Ok, now that SOLR-8280 is resolved the same basic patch (with one minor
conflict resolution) as before passes all tests. In this new patch I've
removed most of the explicit declarations of solr.SchemaSimilarityFactory from
the various tests schema files since it's now the implicit default. A few
special circumstances...
* schema-sim.xml - used by TestPerFieldSimilarityClassic which overrides the
luceneMatchVersion so we have to be explicit that we want it to be the global
sim.
* schema-class-name-shortening-on-serialization.xml - the purpose of this file
is for TestClassNameShortening, so we need to leave the "short" name here in
this config to test the proper behavior
* TestSchemaSimilarityResource.testGetSchemaSimilarity - was previously used
the short class name for SchemaSimilarityFactory since that's what was
explicitly mentioned in schema-rest.xml, so i changed the test to expect the
FQN for the class -- which is the default behavior of the REST API for
implicitly defined instances.
...i think we're good to go.
> 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
> 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]
