[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=16250884#comment-16250884 ]

Erick Erickson commented on SOLR-11624:

I think I see how you're thinking about this. I think it's too much effort, unnecessarily complex and there's too many ways it can fail. Not to mention startling to veteran users.

*Failure case*: User creates a collection and we copy {{_default}} with our prefix. User uses the config API or schema API to modify. User drops collection. The user's work disappears. Hair tearing ensues.

*Failure case*: User creates a collection and  we copy {{_default}}. User is learning about configsets and uploads customized configs manually to the same place 'cause "Hey! that's where my configset is!". User deletes collection and work disappears. Remaining hair is torn out.

*Failure case*: User manually creates a configset prefixed by {{SOLR_CONFIGSET}} 'cause "Hey, that's the convention apparently" then drops the associated collection. We remove the configset, again losing his work. User is now bald and head explodes.

*Failure case N+1*: I'm sure we'll find more.

Sure, each failure case can be fixed with enough coding, but why bother just to keep configsets from proliferating? As I see it, the only thing this mechanism is really helping with is:

{{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. }}

First of all, if the user is dropping and recreating the same collection there's no problem, they'll just continue to use the same configset that was copied the first time.

Second, after that bit of hand-holding users will soon have to be aware of configsets. Especially since every time they create a collection with the {{_default}} configset (or a copy) there's a warning in the response *telling the user that this isn't a good idea* (that should stay  BTW)! I don't think it's too much to ask for them to use the configs API to delete old configsets if they create/drop a bunch of different collections and we copy {{_defalut}} around. Until then having configsets proliferate isn't a big deal IMO.

I don't think your argument below is germane. Maybe I'm stringing two sentences together that weren't intended...
{{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.}}

How did the user screw up a configset if she was unaware of it in the first place? I guess you can argue that she messed it up by using the config API or the managed schema API. IMO it's totally reasonable to expect anyone at that level to use the configs API to delete the configset if they need to start over.

I claim a user will have to eventually be aware of configsets and the added burden of using the configs API to delete unwanted ones after they figure configsets out is preferable to adding to the complexity and potential errors by trying to fix the one use case I see this addressing. If we go this route it won't need any new flags for the collections DELETE command.

What other use-cases do you see that need supporting besides proliferating configsets?

> _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

To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]