[
https://issues.apache.org/jira/browse/SOLR-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711776#comment-14711776
]
Gregory Chanan commented on SOLR-7967:
--------------------------------------
Thanks for the discussion Hoss Man, those questions were very helpful.
At a high level, the use case is to provide an immutable configuration as a
"template" for others to build their own configuration on top of. This could
be generic templates e.g. in a distribution or as a company/use case specific
template. In SolrCloud mode, this allows an administrator to provide these
templates and in combination with a "ConfigSet" API (SOLR-7789), a collection
administrator can create their own configuration without writing directly to
ZooKeeper (which is problematic from a security perspective).
Given that use case, I believe the answers to your questions are:
{quote}what, logically, should be the default behavior of (Immutable)
ConfigSets and a data driven schema?{quote}
Attempts to modify an immutable ConfigSet via a data driven schema should
result in an error, since it is an attempt to modify an immutable / company
sanctioned template.
{quote}what might users reasonably want to do to in conjunction with
(Immutable) ConfigSets and a data driven schema?{quote}
Users may want to base their configuration on a template and use a data driven
schema to update their own configuration. They can do this by creating their
own non-immutable ConfigSet using the API (SOLR-7789) and using the data driven
schema based on that template.
> AddSchemaFieldsUpdateProcessorFactory does not check if the ConfigSet is
> immutable
> ----------------------------------------------------------------------------------
>
> Key: SOLR-7967
> URL: https://issues.apache.org/jira/browse/SOLR-7967
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.3, Trunk
> Reporter: Gregory Chanan
>
> SOLR-7742 introduced Immutable ConfigSets. There are checks added to
> SolrConfigHandler and SchemaHandler so that if a user tries to modify the
> SolrConfig or the Schema via either of these interfaces an error is returned
> if the ConfigSet is defined to be immutable.
> Updates to the schema made via the AddSchemaFieldsUpdateProcessorFactory are
> not checked in this way. I'm not certain this should be considered a bug. A
> ConfigSet is defined by \{SolrConfig, Schema, ConfigSetProperties\}. On one
> hand, you can argue that you are modifying the Schema, which is part of the
> ConfigSet, so the immutable check should apply. On the other hand, the
> SolrConfig (which defines the AddSchema...Factory} defines that it wants the
> Config to be updated, so if you view the ConfigSet in totality you could
> argue nothing is really changing. I'd slightly lean towards adding the check,
> but could go either way.
> Other opinions?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
