[
https://issues.apache.org/jira/browse/SOLR-11488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204491#comment-16204491
]
Varun Thacker commented on SOLR-11488:
--------------------------------------
I'd hate to tell users that the alias re-index strategy will no longer work.
bq. This is kind of a pain, but much better than following an alias and
deleting "new"
Do you mean someone wants to delete data or add data and it ends up in the
wrong collection?
Here's an idea Shalin and I had long back discussed :
Whenever someone creates a collection {{foo}} Solr should do two things under
the hood
- Internally store the collection as {{_foo}}
- Create an alias "foo"
Never allow users to create aliases with an underscore prefix
All routing logic in Solr ( CloudSolrClient / HttpSolrCall ) only check if the
{{foo}} alias exists and then fetches the underlying collection details and
processes the request.
Today the routing logic first checks if an alias exists . If it doesn't it
checks if an actual collection with the name exists. I believe we are trying to
solve this ambiguity problem for more consistent routing logic and the approach
mentioned probably addresses the concerns?
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
