[
https://issues.apache.org/jira/browse/SOLR-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17581973#comment-17581973
]
Chris M. Hostetter commented on SOLR-16305:
-------------------------------------------
{quote}I think of this as an enhancement, not a bug.
{quote}
It seems pretty clear cut to me: We have documented support for
{{MODIFYCOLLECTION}} being used to change {{property.*}} commands set when
creating a collection, and SolrJ helper methods for making this easy, but
(AFAICT) these params are then 100% completely ignored on the server side.
(Well ... not completely ignored: the Collections API param validation logic
that rejects unexpected params explicitly allows params with the {{property.*}}
prefix ... and _then_ ignores them)
Seems like a pretty clear cut bug to me.
{quote}I think we should put custom properties into the Collection's state.json
so that ZK is the source of truth. ...
...
We could use Collection Properties for this, even though it's not state.json.
{quote}
I assume this second bit is in reference to the {{COLLECTIONPROP}} API command?
I'm not very familiar with that command (when/why it was added, what it does,
what it's intended usecase is ... the docs are basically non existent) but if
it can be used to set arbitrary properties that can be used as variables in
{{solrconfig.xml}} then i'm +1 to using it under the covers of {{CREATE}} and
{{MODIFYCOLLECTION}} to get teh props into ZK instead of writing them to
{{core.properties}} -- but I don't think we can just document "Use the
{{COLLECTIONPROP}} command to do this" because there's a chicken/egg ordering
problem: {{CREATE}} spins up the replicas which won't have the props set so
core loading will fail, and you can'd do the {{COLLECTIONPROP}} command before
the {{CREATE}} because it will (hopefully?) fail on the unrecognized collection
name.
I suppose it's possible people might have a strong reason why they want the
props written to {{core.properties}} ? ... maybe we could add a
"not-quite-backcompat" support for {{core.property.*}} in {{CREATE}} for folks
that _really_ want it in {{core.properties}} (and just be clear that
{{MODIFYCOLLECTION}} can't be used to change those ) ?
> 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
