[
https://issues.apache.org/jira/browse/SOLR-11624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16248591#comment-16248591
]
Erick Erickson commented on SOLR-11624:
---------------------------------------
Hmm, problem is we can't satisfy both a new user in the scenario you outline
_and_ someone taking control of their configsets. The situation we're in now is
> user tunes their configuration set like we want them to. We even tell them
> that _default isn't recommended for production!
> user creates a collection without specifying configName
> user loses their changes _and_ gets schemaless to boot. Yes, they can start
> with the "don't add new fields" parameter....
If I imagine it from the perspective of a brand-new user, then this becomes one
of those little "learning experiences".
If I imagine this from the perspective of a veteran user then the behavior is a
real head-scratcher.
And _much_worse IMO.
> user _does_ understand configsets
> user creates collection1 and gets configset collection1 copied from _default
> and makes modifications.
> user creates 10 more collections all using collection1 configset
> user drops and recreates collection1. Now all 10 collections are back to
> _default
So really we've made it very easy for veteran users to mess up in order to make
it easy for a new user to start from a known state when dropping and recreating
a collection. It can take considerable time and effort to get your configs the
way you want them, and all that work is potentially lost. Additionally it's
very common to recommend that users drop and recreate collections to re-index
from scratch.
Of the two I'd rather add the need to delete the configset when a user wants to
start over to the learning curve rather than mess up veteran's work.
So I'm +1 for reverting.
What do you think about this: We already have a warning when using the _default
schema about how schemaless isn't recommended for production. To cover the
situation Ishan outlined, we return a message like "Using existing
configuration set XXX" if a configset already exists? And do this even if they
specify configName.
Actually I kind of like that idea anyway as an additional confirmation that the
user did what they wanted.
And another suggestion re: the message returned. The current message will still
come back if a configset with the same name as the collection does _not_ exist.
Rather than say "Using _default configset..." how about something telling them
that the configset has been copied? the current wording is easy to interpret as
the collection is actually using _default rather than a copy of it. "Copied
the _default configset to <collection_name> which will be used by this
collection..." or something.
> _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]
