[
https://issues.apache.org/jira/browse/SOLR-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764689#comment-17764689
]
Vincent Primault commented on SOLR-16305:
-----------------------------------------
I found this ticket while trying to understand the difference between
MODIFYCOLLECTION and COLLECTIONPROP and the propagation flow of property.*
properties. I was also surprised by the semantics of COLLECTIONPROP, which does
not store the properties in cluster state, as opposed to similar user-defined
properties for replicas which are indeed stored in cluster state (despite
sharing the same API in v2).
For my use case, I would like to define some user-defined properties at the
collection-level, and propagate them to the core. What I am missing is 1/ the
fact that those properties are not stored with the collection, but only used
when creating cores 2/ not reused when creating new shard or replicas for this
collection. After defining the "foo" property when creating the collection, I
would need further calls to ADDREPLICA to also reuse those collection-level
user-defined properties.
My proposal is then the following:
* Store user-defined properties in cluster state at collection-level (coming
from create collection/modify collection)
* Store user-defined properties in cluster state at replica-level (coming from
create replica/add replica prop/delete replica prop)
* Inherit from user-defined properties from collection and replica when
creating cores.
I believe it makes sense to inherit from properties to ensure consistency
between the first call creating a collection and first replicas, and the
subsequent ones. It also gives semantics to modifying user-defined properties
of a collection or replica: they do not affect existing cores, but all cores
created after that.
> MODIFYCOLLECTION with 'property.*' changes can't change values used in config
> file variables (even though they can be set during collection CREATE)
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-16305
> URL: https://issues.apache.org/jira/browse/SOLR-16305
> Project: Solr
> Issue Type: Bug
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-16305_test.patch
>
>
> Consider a configset with a {{solrconfig.xml}} that includes a snippet like
> this...
> {code:java}
> <str name="param.check">${custom.prop:customDefVal}</str>
> {code}
> ...this {{custom.prop}} can be set when doing a {{CREATE}} command for a
> collection that uses this configset, using the {{property.*}} prefix as noted
> in the reg-guide...
> {quote}{{property.{_}name{_}={_}value{_}}}
> |Optional|Default: none|
> Set core property _name_ to {_}value{_}. See the section [Core
> Discovery|https://solr.apache.org/guide/solr/latest/configuration-guide/core-discovery.html]
> for details on supported properties and values.
> {quote}
> ...BUT....
> These values can *not* be changed by using the {{MODIFYCOLLECTION}} command,
> in spite of the ref-guide indicating that it can be used to modify custom
> {{property.*}} attributes...
> {quote}The attributes that can be modified are:
> * {{replicationFactor}}
> * {{collection.configName}}
> * {{readOnly}}
> * other custom properties that use a {{property.}} prefix
> See the [CREATE
> action|https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#create]
> section above for details on these attributes.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
