[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16250666#comment-16250666
]
Noble Paul commented on SOLR-11624:
-----------------------------------
{code}
> I create collection EOE, SOLR_CONFIGSET.EOE is created by Solr
> I customize the configset.
> I create 3 more collections pointing to it.
> I drop and recreate collection EOE.
> my other three collections now use the default configset with who knows what
> consequences?
{code}
In this case {{SOLR_CONFIGSET.EOE}} is referenced by another live collection.
So, it does not get deleted
bq.This does not address the root problem: the current behavior overwrites an
existing configset that I may have modified. I don't care how it was created,
this is the root problem that I'm -Integer.MAX_VALUE on.
I don't think we are talking against each other. We don't need to delete an
existing confgset.
bq.The principle of least surprise comes in to play here. Once a configset
exists in ZooKeeper, don't change it unless I tell you to. End of story.
Take the use case of a casual user creating and deleting collections. very
soon, we will end up a lot of unused configsets in zookeeper. The user did not
create the configset, so he is not aware of its existence. Imagine he screwed
up the configset while he was using the collection and he wanted to start with
a clean slate. In order to do so, he would delete a collection and recreate
another (most likely with the same name). He will see the screwed up behavior
again because the old configset gets reused. So, my proposal was
* Use a special name for auto-created configsets (such as
{{SOLR_CONFIGSET.<collection-name>}}) This eliminates the problem of us
screwing up our current user base who creates configsets with the same name as
the collection
* As you said, DO NOT delete/overwrite a configset at the time of collection
creation
* When deleting a collection, that has an auto created configset, drop it.
Because, the user did not ask us to create the configset and most likely he is
unaware of it. If that configset is referenced by another collection, do not
delete it.
* We can also provide a flag in DELETE-COLLECTION to omit dropping of
configset.
> _default configset overwrites a a configset if collection.configName isn't
> specified even if a confiset of the same name already exists.
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> 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: Erick Erickson
> Attachments: 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: [email protected]
For additional commands, e-mail: [email protected]
