[
https://issues.apache.org/jira/browse/SOLR-11488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-11488:
-------------------------------------
Assignee: (was: Erick Erickson)
> Do not allow collections and aliases to have the same name
> ----------------------------------------------------------
>
> Key: SOLR-11488
> URL: https://issues.apache.org/jira/browse/SOLR-11488
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Attachments: SOLR-11488.patch
>
>
> Currently you can define an alias with the same name as a collection and
> (perhaps) vice-versa. The more I think about this the worse idea it seems.
> See the discussion at the linked JIRAs.
> Proposal: We should fail to create a collection if an alias already exists
> with the same name and vice-versa.
> This should depend on SOLR-11444 and supersede SOLR-11218, this JIRA will
> include tests that define the intended behavior making SOLR-11218 obsolete.
> We'll close SOLR-11218 as "contained by" this JIRA.
> This _will_ take away the ability to
> 1> create a collection, call it "old" and index to it.
> 2> decide you want to change the schema
> 3> create a collection call it "new" and index to it.
> 4> create an alias old->new THIS WILL FAIL.
> 5> delete the "old" collection
> People will have to create an alias pointing to "old" and change their
> clients to use it, then they can do step 4 above....
> This is kind of a pain, but much better than following an alias and deleting
> "new". I'd also argue that it's a maintenance problem to have collections and
> aliases with the same name.
> What do people think? I'll try to work up a preliminary patch. If we do this,
> we should probably coordinate committing this and SOLR-11444 and I'll also
> change the docs to reflect this and upgrade notes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
