# Problem with index aliases and delete operation?
**URL:** https://discuss.elastic.co/t/problem-with-index-aliases-and-delete-operation/9331
**Category:** Elasticsearch
**Created:** [October 11, 2012, 10:36pm UTC](https://discuss.elastic.co/t/problem-with-index-aliases-and-delete-operation/9331 "2012-10-11T22:36:48Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Benjamin\_Deveze](https://discuss.elastic.co/u/Benjamin_Deveze)
#### Post date: [October 11, 2012, 10:36pm UTC](https://discuss.elastic.co/t/problem-with-index-aliases-and-delete-operation/9331/1 "2012-10-11T22:36:48Z")
Suppose we use the "usersdata flow" exposed in kimchy's "Big Data, Search
and Analytics" presentation to index users documents in a big oversharded
index with routing+filtering aliases. Some users content are moved to their
own index when becoming too big.
From the client perspective we don't know if we are manipulating a virtual
index via an alias or a real index dedicated to the user and the code
should be the same. So if an user is deleted and we want to remove its
content the client code do something like curl -XDELETE
localhost:9200/$INDEX\_NAME. The power of aliasing being that the client is
agnostic of knowing if it deals with a real index or an aliased one.
But with the current behavior if $INDEX\_NAME is an alias the whole big
oversharded index will be deleted and all users document are lost!
IMHO it is really dangerous. I was expecting a simple delete index if the
$INDEX\_NAME is a real index under the hood and maybe a delete by query
(even if it is expensive) or at least a failure or something like that
maybe configurable via a parameter if $INDEX\_NAME is an alias linking to
the big oversharded index.
What do you think?
--
---
### Author:  [@Chris\_Male](https://discuss.elastic.co/u/Chris_Male)
#### Post date: [October 11, 2012, 11:30pm UTC](https://discuss.elastic.co/t/problem-with-index-aliases-and-delete-operation/9331/2 "2012-10-11T23:30:30Z")
That does sound a little unexpected, certainly in the use case you put
forward. Why don't you open an issue so we can explore what improvements
can be made at the code level.
On Friday, October 12, 2012 11:36:48 AM UTC+13, Benjamin Devèze wrote:
> Suppose we use the "usersdata flow" exposed in kimchy's "Big Data, Search
> and Analytics" presentation to index users documents in a big oversharded
> index with routing+filtering aliases. Some users content are moved to their
> own index when becoming too big.
>
> From the client perspective we don't know if we are manipulating a virtual
> index via an alias or a real index dedicated to the user and the code
> should be the same. So if an user is deleted and we want to remove its
> content the client code do something like curl -XDELETE
> localhost:9200/$INDEX\_NAME. The power of aliasing being that the client is
> agnostic of knowing if it deals with a real index or an aliased one.
>
> But with the current behavior if $INDEX\_NAME is an alias the whole big
> oversharded index will be deleted and all users document are lost!
>
> IMHO it is really dangerous. I was expecting a simple delete index if the
> $INDEX\_NAME is a real index under the hood and maybe a delete by query
> (even if it is expensive) or at least a failure or something like that
> maybe configurable via a parameter if $INDEX\_NAME is an alias linking to
> the big oversharded index.
>
> What do you think?
--
---
### Author:  [@Benjamin\_Deveze](https://discuss.elastic.co/u/Benjamin_Deveze)
#### Post date: [October 12, 2012, 6:46am UTC](https://discuss.elastic.co/t/problem-with-index-aliases-and-delete-operation/9331/3 "2012-10-12T06:46:48Z")
Thanks!
Done here [Index aliases and delete operation · Issue #2318 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/2318)
On Friday, October 12, 2012 1:30:30 AM UTC+2, Chris Male wrote:
> That does sound a little unexpected, certainly in the use case you put
> forward. Why don't you open an issue so we can explore what improvements
> can be made at the code level.
>
> On Friday, October 12, 2012 11:36:48 AM UTC+13, Benjamin Devèze wrote:
>
> > Suppose we use the "usersdata flow" exposed in kimchy's "Big Data, Search
> > and Analytics" presentation to index users documents in a big oversharded
> > index with routing+filtering aliases. Some users content are moved to their
> > own index when becoming too big.
> >
> > From the client perspective we don't know if we are manipulating a
> > virtual index via an alias or a real index dedicated to the user and the
> > code should be the same. So if an user is deleted and we want to remove its
> > content the client code do something like curl -XDELETE
> > localhost:9200/$INDEX\_NAME. The power of aliasing being that the client is
> > agnostic of knowing if it deals with a real index or an aliased one.
> >
> > But with the current behavior if $INDEX\_NAME is an alias the whole big
> > oversharded index will be deleted and all users document are lost!
> >
> > IMHO it is really dangerous. I was expecting a simple delete index if the
> > $INDEX\_NAME is a real index under the hood and maybe a delete by query
> > (even if it is expensive) or at least a failure or something like that
> > maybe configurable via a parameter if $INDEX\_NAME is an alias linking to
> > the big oversharded index.
> >
> > What do you think?
--
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 3:09am UTC](https://discuss.elastic.co/t/problem-with-index-aliases-and-delete-operation/9331/4 "2017-07-06T03:09:08Z")