[ 
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

Reply via email to