You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2015/11/12 02:06:10 UTC
[jira] [Updated] (SOLR-8271) use SchemaSimilarityFactory as default
when no explicit (top level) sim is configured
[ 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
Initial simple patch, currently causes failures in TestCloudSchemaless & ChangedSchemaMergeTest.
These are the same failures I noted in the early attempts at SOLR-8057. Earlier today I thought that was because I was being silly in that old patch and needed to use the SolrResourceLoader to create the sin factory so SolrCoreAware.inform would be called appropriately in all situations -- which I do in this patch. But the failures persist. Digging into it I realized the same problem could easily be reproduced via configs -- so this issue is currently bloced until we can get to the bottom of SOLR-8280.
> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org