You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2023/03/29 21:56:00 UTC

[jira] [Commented] (SOLR-12420) Propose removing schema version; use luceneMatchVersion instead

    [ https://issues.apache.org/jira/browse/SOLR-12420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706621#comment-17706621 ] 

Chris M. Hostetter commented on SOLR-12420:
-------------------------------------------

{quote}Schema version is used to determine defaults for a schema, ...  So a user can move the same schema from Solr 8.1 to Solr 9.0 and get the same search behavior. We could achieve some of the same by locking it to the luceneMatchVersion, or we could eliminate version and say that everyone gets latest behavior from Solr X.  But that will make it hard to introudce new schema defaults in a minor release.
{quote}
It's not just about minor releases – a person should be able to move their configset/schema from Solr9.x to Solr10 (even if they have to reindex) and still get the same behavior  – or if that behavior is no longer supported, a clear error.  They should never silently get differnet behavior with the same configs.

That's always been the real power & purpose behind why we had a {{version}} property in {{schema.xml}} (and later added  {{luceneMatchVersion}} to {{solrconfig.xml}}

----

FWIW: now that Lucene and Solr have independent version numbers, the idea of removing the schema {{version}} and deducing all of the "what should the default be for unspecfied fieldType options" decisions from {{luceneMatchVersion} would _now_ mean we can't change any solr specific behavior between solrVersion X and solrVersion Y unless we have also upgraded lucene between those two versions -- which is an obnoxious limitation.

> Propose removing schema version; use luceneMatchVersion instead
> ---------------------------------------------------------------
>
>                 Key: SOLR-12420
>                 URL: https://issues.apache.org/jira/browse/SOLR-12420
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: David Smiley
>            Priority: Blocker
>             Fix For: main (10.0)
>
>
> I propose that the schema version be removed in lieu of using luceneMatchVersion for this.  One less thing to manage (in code, need REST API -- SOLR-7242, thing to document; etc.).  We don't need the fidelity to differentiate from luceneMatchVersion.  We're already using luceneMatchVersion for things instead of having a ton of additional version numbers.  I can understand the point of putting a version number in in a config file but I don't think we should continue this practice.
> To make this happen, if the luceneMatchVersion is >= 7.4 (the release which we start doing this) then a non-existent schema version becomes equivalent to the latest schema version.  Specifying the schema version becomes deprecated but supported; we might log a warning. 
> In 8.0, strip schema version out altogether.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org