[jira] [Commented] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (SOLR-11624) _default configset overwrites a a configset if collection.configName isn't specified even if a confiset of the same name already exists.

JIRA jira@apache.org

    [ 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: [hidden email]
For additional commands, e-mail: [hidden email]