The main reason for the limitation is basically the response, which is a
single "index" and not something similar to bulk response. We could simply
translates such an index operation to a bulk operation and do it against
multiple indices, but then representing the response is problematic... .
Open for ideas here, possibly we could have "additional" response section
with all the response, or something similar...
On Wed, May 9, 2012 at 7:51 PM, Nicolas Lalevée
nicolas.lalevee@hibnet.orgwrote:
It would be useful when I want to do a major change in the mapping. Say I
have one index, being used for read and write. Now I create a new index
with a new mapping. I want then to have queries still querying the first
index, while write go throughout both, and a full reindex goes on the
second. When the full reindex is finished, I can then use it for read. And
the first index can be deleted. Smooth transition.
Currently all of this is managed on the client side, a conf in the db list
the read and write indices. For the read, I am changing it so it will be
managed via an alias. I was expecting to use aliases for write too but it
is not possible the doc says [1]:
"It is an error to index to an alias which points to more than one index."I'm a wondering why a such limitation.
Nicolas
[1]
Elasticsearch Platform — Find real-time answers at scale | Elastic