[
https://issues.apache.org/jira/browse/SOLR-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204736#comment-16204736
]
Erick Erickson commented on SOLR-11489:
---------------------------------------
Only one of these JIRAs should be implemented. We'll close the one not
implemented as "is superceded by" or something.
> 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: [email protected]
For additional commands, e-mail: [email protected]
