lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <>
Subject [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.
Date Tue, 14 Nov 2017 05:22:00 GMT


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:
>             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:
For additional commands, e-mail:

View raw message