You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea is for the Restore API to be able to fit the snapshoted data into a new mapping, if the new mapping is compatible.
For example, one may change the analyzer for a string field, and the Restore API should fill the new index with the same string data but honoring the new mapping.
It seems to me that according to #5210, it was already the case previously.
Here is what I propose:
The Restore API should expose a parameter "new_index" (or even "new_type" if type level restore is possible) which is the name of the index that use the new mapping.
If no "new_index" is specified then the fixed in Restore of an existing index doesn’t restore mappings and settings #5210 should be effective.
Ultimately an API that hide the complexity of same cluster restore. Hence one can change the mapping of a index on the fly with a single API call.
(Related) Maybe the same can be done by "update by query", if there is a way to traverse the whole index/type natively and use the result to fill the new index.
The text was updated successfully, but these errors were encountered:
Hi @lordaugustus I'm afraid what you are asking is not possible through snapshot/restore API as it doesn't actually reindex any data, it just copies around segments from the different lucene indices, without making any change to the underlying data structures. What you are asking is more like a reindex operation, which indeed would require to reindex the documents and possibly allow to change their mappings, more like #492 or #1655.
Note that this can be done by using a scan search and reindexing into a new index all of the returned documents.
The idea is for the Restore API to be able to fit the snapshoted data into a new mapping, if the new mapping is compatible.
For example, one may change the analyzer for a string field, and the Restore API should fill the new index with the same string data but honoring the new mapping.
It seems to me that according to #5210, it was already the case previously.
Here is what I propose:
If no "new_index" is specified then the fixed in Restore of an existing index doesn’t restore mappings and settings #5210 should be effective.
The text was updated successfully, but these errors were encountered: