You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Andrzej Bialecki (Jira)" <ji...@apache.org> on 2022/10/11 16:29:00 UTC

[jira] [Commented] (SOLR-16305) MODIFYCOLLECTION with 'property.*' changes can't change values used in config file variables (even though they can be set during collection CREATE)

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

Andrzej Bialecki commented on SOLR-16305:
-----------------------------------------

AFAIK the propagation of `property.*` values to cores is accidental, the original purpose (again, AFAIK) was to be able to set aux properties in the `state.json`, to keep additional per-collection state that could be used by other components. The advantage of this is that they would automatically appear in DocCollection at the API level (unlike COLLECTIONPROP API which is incomplete, because only the "write" part is supported but not "read", without going directly to ZK. AFAIK the COLLECTIONPROP was added because routed aliases needed some place to keep additional state, potentially too large / inconvenient to stick into state.json.)

However, even using these `property.*` values is half-broken, as I recently discovered - it's supported in MODIFYCOLLECTION but not in CREATE, due to `ClusterStateMutator.createCollection()` copying only the predefined properties and ignoring anything else.

This should be fixed in some way - I'm inclined to say in both ways ;) that is, the COLLECTIONPROP API should be completed so that it includes the reading part, and the CREATE should be fixed to accept `property.*`. And I don't see the purpose of propagating these collection-level props to individual cores, so this part could be removed until it's needed.

> 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
>      Security Level: Public(Default Security Level. Issues are Public) 
>            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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org