[
https://issues.apache.org/jira/browse/SOLR-14986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227418#comment-17227418
]
Erick Erickson commented on SOLR-14986:
---------------------------------------
I want some opinions on what to do here. Thinking about this, there are two
sets of values that could potentially conflict with what Solr expects that can
be specified with *property.name=value*.
One set is all the stuff you can put on the URL. For the CREATE command, things
like *numShards*, *shards*, *replicationFactor*. For ADDREPLICA, things like
*dataDir*, *type*....
Should the following call fail on the theory that "the user is demonstrating a
fundamental lack of understanding so let's make them stop and read the manual?"
{code:java}
admin/collection?action=CREATE&numShards=3&property.numShards=5...
{code}
Even though *numShards* doesn't go into core.properties, the above is weird.
The other set is those entries in core.properties that we put there
automagically, things like *coreNodeName*, *shard* and the like. A command like
{code:java}
admin/collection?action=ADDREPLICA&property.coreNodeName=someting...
{code}
is dangerous, 'cause if it succeeds and is done more than once, the results
would be "interesting". I believe it fails BTW, but not by explicit check. I
can say for certainty that other mixed-up calls like this fail with opaque
errors. There's an example in the original description.
I propose to fail both situations with an informative error message very early
in processing.
> Restrict the properties possible to define with "property.name=value" when
> creating a collection
> ------------------------------------------------------------------------------------------------
>
> Key: SOLR-14986
> URL: https://issues.apache.org/jira/browse/SOLR-14986
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> This came to light when I was looking at two user-list questions where people
> try to manually define core.properties to define _replicas_ in SolrCloud.
> There are two related issues:
> 1> You can do things like "action=CREATE&name=eoe&property.collection=blivet"
> which results in an opaque error about "could not create replica....." I
> propose we return a better error here like "property.collection should not be
> specified when creating a collection". What do people think about the rest of
> the auto-created properties on collection creation?
> coreNodeName
> collection.configName
> name
> numShards
> shard
> collection
> replicaType
> "name" seems to be OK to change, although i don't see anyplace anyone can
> actually see it afterwards....
> 2> Change the ref guide to steer people away from attempting to manually
> create a core.properties file to define cores/replicas in SolrCloud. There's
> no warning on the "defining-core-properties.adoc" for instance. Additionally
> there should be some kind of message on the collections API documentation
> about not trying to set the properties in <1> on the CREATE command.
> <2> used to actually work (apparently) with legacyCloud...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
