[
https://issues.apache.org/jira/browse/SOLR-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14529646#comment-14529646
]
Erick Erickson commented on SOLR-7499:
--------------------------------------
I can go both ways on this. On the one hand, it's perfectly legitimate for an
admin to want to have full control over the replica names. OTOH, it's a fine
way to shoot oneself in the foot.
It seems to me that we either remove it or make it safe. "Make it safe" means
check up-front for any other core with the same name anywhere in the collection
(not just on the same node) and fail if one exists.
Overall, though, since we don't allow the user to specify names of cores when
creating collections, there's no real reason to allow it on the ADDREPLICA
command so let's nuke it, or at least remove it from the docs and call it
"expert".
> Remove/Deprecate the "name" parameter from the ADDREPLICA Collection API call
> -----------------------------------------------------------------------------
>
> Key: SOLR-7499
> URL: https://issues.apache.org/jira/browse/SOLR-7499
> Project: Solr
> Issue Type: Bug
> Reporter: Varun Thacker
> Priority: Minor
>
> Right now we take a "name" parameter in the ADDREPLICA call. We use that as
> the core name for the replica. Are there any use cases where specifying the
> name of the core for the replica is useful?
> Here are the disadvantages of doing so -
> 1. We don't verify if the name is unique in the collection. So if a
> conflicting name ends up in the same node then the call will fail.
> 2. If it core is created on some other node, it will fail with
> legacyCloud=false as that checks for uniqueness in core names.
> https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api_addreplica
> - The ref guide has never documented the "name" parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
