[
https://issues.apache.org/jira/browse/SOLR-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17931555#comment-17931555
]
Jason Gerlowski commented on SOLR-17687:
----------------------------------------
One question is how to handle deployments that have taken advantage of this
MODIFYCOLLECTION quirk, and have these properties persisted in their ZK state.
I can think of three options:
# *Automatic Migration* - have *something* in Solr notice these
"user-specified" metadata props, create collection-property equivalents, and
delete the legacy values. This is the most upfront work, but maybe provides
the best user experience? (Though it could be argued that doing the migration
"quietly" actually might mislead users who have automation expecting the
properties in a particular place.)
# *Manual Migration* - create scripts external to Solr that a user can run
themselves to detect which "user-specified" metadata props are present, create
collection-property equivalents, and delete the legacy values. Document in
changelog etc. that users doing a rolling or in-place upgrade to a new major
version should run these scripts prior to upgrading to make sure that their
property usage is compliant before reaching 10.0
# *Do Nothing* - Solr 10.0 and above could choose to parse collection-state
leniently and ignore any "unexpected" metadata properties altogether. This is
simple and avoids a lot of the thorny questions of the "Automatic Migration"
option above, but it leaves the ZK state unchanged.
> Deprecate and remove arbitrary props in MODIFYCOLLECTION
> --------------------------------------------------------
>
> Key: SOLR-17687
> URL: https://issues.apache.org/jira/browse/SOLR-17687
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 9.8
> Reporter: Jason Gerlowski
> Priority: Major
>
> SOLR-13271 (which primarily targeted "readOnly" mode for collections) added
> the ability to specify arbitrary (also called "user-provided") properties to
> store alongside other collection metadata (like numShards, replicationFactor,
> etc.).
> We should deprecate (and ultimately remove) this support, since it is
> redundant with SolrCloud's better known and supported "collection property"
> capability.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
