[
https://issues.apache.org/jira/browse/SOLR-11488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205212#comment-16205212
]
David Smiley commented on SOLR-11488:
-------------------------------------
bq. "aliases take precedence" would do exactly what I don't want in the reindex
case.
For the reindex case: If aliases aren't allowed to recursively resolve (aliases
pointing to aliases) -- and I don't like it FWIW, then you could still usefully
have aliases with the same name as a collection for the re-index case. Here,
you would use another alias for the re-index that refers to the underlying
collection to get a full import of new data. In this scenario, you might
migrate from an initially alias-less setup (initially not knowing if you needed
them), to eventually having an 'A' and 'B' collection, probably eventually
deleting the original collection to avoid confusion with the alias, although it
wouldn't be necessary to do that. All through this, searching clients needn't
change. Ad-hoc updates probably needn't change either. The re-index client
process would need to be aware of this scheme though, which is fair enough as
it's likely the one orchestrating this shell game.
bq. So I'll change 11218 to reflect just that we need to beef up alias tests in
general and particularly for admin operations and we'll go from there?
+1
> 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
> Assignee: 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: [email protected]
For additional commands, e-mail: [email protected]
