You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "David Smiley (JIRA)" <ji...@apache.org> on 2017/12/29 20:50:00 UTC
[jira] [Commented] (SOLR-11624) collection creation should not also
overwrite/delete any configset but it can!
[ https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16306533#comment-16306533 ]
David Smiley commented on SOLR-11624:
-------------------------------------
Abhishek, when adding updated attachments to JIRA, use the same name and JIRA will keep track of it (clearly showing which is the latest yet allowing access to earlier ones if desired). Do not keep incrementing a counter at the suffix.
FWIW I don't think the auto created suffix name needs "CONFIGSET" as a part of it's name, as that is the namespace in which it exists :-) (and it's verbose). I think a suffix of ".AUTOCREATED" is fine.
I briefly looked at two aspects of your patch; it wasn't thorough.
RE TimeRoutedAliasUpdateProcessorTest: it seems that your changes resulted in the creation of an auto-generated configset, but I definitely do not want autogenerated configsets in the test. I believe this is easily avoided by having the collection creation explicitly refer to the desired configset when it's created.
Here are the updated docs you added to the collection.configName parameter:
bq. Defines the name of the configurations (which *must already be stored in ZooKeeper*) to use for this collection. If not provided, Solr will use the configurations of `_default` configSet *OR* `the only configSet present` (if there is only 1 config set in Zookeeper) to create the collection. The new configSet created for the collection will be named `<collectionName>.AUTOCREATED_CONFIGSET`
I think it needs to be clear that Solr will create a new (mutable) configSet that is a copy of _default, and that this new configSet will be deleted when the collection is. The \*OR\* part has my attention. I assume this rule is for legacy? Any way, so if we have one configSet in ZooKeeper named "myconfig" and the user creates a collection "mycoll" (without specifying which config), then presumably we'll have two configSets: "myconfig" and "mycoll.AUTOCREATED_CONFIGSET". And this point there is no longer one configSet in ZooKeeper, nor is there "_default" for that matter. Does this mean if the user goes to create another collection similarly that it will fail? Presumably you didn't introduce this behavior but you are documenting it? Can someone vouch for the usefulness of this behavior; I find it problematic.
Nippick: "configurations" should be in singular form in both places.
> collection creation should not also overwrite/delete any configset but it can!
> ------------------------------------------------------------------------------
>
> Key: SOLR-11624
> URL: https://issues.apache.org/jira/browse/SOLR-11624
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.2
> Reporter: Erick Erickson
> Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-11624-2.patch, SOLR-11624.3.patch, SOLR-11624.4.patch, SOLR-11624.patch
>
>
> Looks like a problem that crept in when we changed the _default configset stuff.
> setup:
> upload a configset named "wiki"
> collections?action=CREATE&name=wiki&.....
> My custom configset "wiki" gets overwritten by _default and then used by the "wiki" collection.
> Assigning to myself only because it really needs to be fixed IMO and I don't want to lose track of it. Anyone else please feel free to take it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org