[ 
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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to