You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2017/10/14 17:07:00 UTC

[jira] [Created] (SOLR-11489) Create collections as _foo and auto-create an alias foo->_foo

Erick Erickson created SOLR-11489:
-------------------------------------

             Summary: Create collections as _foo and auto-create an alias foo->_foo
                 Key: SOLR-11489
                 URL: https://issues.apache.org/jira/browse/SOLR-11489
             Project: Solr
          Issue Type: Improvement
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Erick Erickson
            Assignee: Erick Erickson


Spin-off from SOLR-11488. Currently if a collection and an alias have the same name we don't test how they're resolved. So an innocent change to the code could easily change the behavior (what happens when you have a collection old, and an alias old->new and delete collection "old"? Have we even defined what _should_ happen?).

See the discussion at SOLR-11488.

An alternative proposal to SOLR-11488 (thanks Varun for pointing it out) is when creating a collection "foo", actually name it _foo and create an alias foo->_foo. Also don't allow the user to create an alias that begins with an underscore (and maybe the same for collections? An alias _foo->__foo starts to get weird).

The result would be we'd never have a collection and an alias with the same name, which would go a long way to prevent issues going forward.

This requires we consider the name in state.json to be an implementation detail, but the user won't notice. Potential here for the list of aliases to be quite large.

Of course the user could still reference the collection directly as _foo if they insisted.

Establishing this JIRA for discussion of the alternatives.

Assigning to myself to keep it from getting lost, feel free to take it over if you'd like.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org