: > We currently support requests to CREATEALIAS to collections that don’t : > exist. Requests to this alias later result in 404s. If the target : > collection is later created, requests to the alias will begin to work. I’m : > wondering if someone is relying on this behavior, or if we should validate : > the existence of the target collections when creating the alias (and thus, : > fail fast in cases of typos or unexpected cluster state)
+1 ... failing fast on ALIAS creation by default seems like the best default behavior, we could always support a new "allowNonExistentCollecions=true" param (defaulting to 'false') for backcompat or advanced users who want to "pre-create" aliases before hte collections. : I’d prefer it if the alias was required to be removed, or pointed : elsewhere, before the collection could be deleted. also +1 ... Having action=DELETE fail on a collection if it's part of any aliases seems like much better (default) behavior then having it proactively delete all aliases the collection is part of. And similar to above, a (new) advanced "removeAnyAliases=true" param (defaulting to false) could be support the more aggressive deletion if folks thik it's an important value add for users. In general I agree with the overall premise that safety values during collection delete (based on pre-existing aliases) should go part and parcel with any safety values we add on alias creation. -Hoss http://www.lucidworks.com/
