[
https://issues.apache.org/jira/browse/SOLR-13583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875002#comment-16875002
]
Gus Heck edited comment on SOLR-13583 at 6/28/19 3:35 PM:
----------------------------------------------------------
Also this issue should probably clarify the intended behavior relative to
[~erickerickson]'s concerns expressed in: SOLR-13122
My $0.02: The current situation of an alias pointing to an alias but only one
level deep is strange. In 9.0 We should either support nesting (arbitrary
depth) or not support it at all. Certainly nesting imposes significant risks
and more work, and I think if we do follow aliases more than one level, we
should provide an additional attribute followAliasMaxDepth (default=1), and
then fail with if it finds some depth greater than the specified maximum,
returning a list of potentially affected collections, aliases involved, and the
depth required to run the command. This is a lot of work, and so not following
aliases in certain documented cases (or complete rollback) to get this ticket
resolved quickly is probably a good option.
was (Author: gus_heck):
Also this issue should probably clarify the intended behavior relative to
[~erickerickson]'s concerns expressed in: SOLR-13122
My $0.02: The current situation of an alias pointing to an alias but only one
level deep is strange. In 9.0 We should either support nesting (arbitrary
depth) or not support it at all. Certainly nesting imposes significant risks
and more work, and I think if we do follow aliases more than one level, we
should provide require an additional attribute followAliasMaxDepth
(default=1), and then fail with if it finds some depth greater than the
specified maximum, returning a list of potentially affected collections,
aliases involved, and the depth required to run the command. This is a lot of
work, and so not following aliases in certain documented cases (or complete
rollback) to get this ticket resolved quickly is probably a good option.
> Impossible to delete a collection with the same name as an existing alias
> -------------------------------------------------------------------------
>
> Key: SOLR-13583
> URL: https://issues.apache.org/jira/browse/SOLR-13583
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 8.1, 8.1.1
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Blocker
> Fix For: 8.1.2
>
>
> SOLR-13262 changed the behavior of most collection admin commands so that
> they always resolve aliases by default. In most cases this is desireable
> behavior but it also prevents executing commands on the collections that have
> the same name as an existing alias (which usually points to a different
> collection).
> This behavior also breaks the REINDEXCOLLECTION command with
> {{removeSource=true,}} which can also lead to data loss.
> This issue can be resolved by adding either an opt-in or opt-out flag to the
> collection admin commands that specifies whether the command should attempt
> resolving the provided name as an alias first. From the point of view of ease
> of use this could be an opt-out option, from the point of view of data safety
> this could be an opt-in option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
