Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using Snapshot-Restore API as a smart way to change mapping #5938

Closed
lordaugustus opened this issue Apr 25, 2014 · 2 comments
Closed

Using Snapshot-Restore API as a smart way to change mapping #5938

lordaugustus opened this issue Apr 25, 2014 · 2 comments

Comments

@lordaugustus
Copy link

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:

  1. 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.
  2. 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.
  3. (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.
@javanna
Copy link
Member

javanna commented Apr 25, 2014

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.

@javanna
Copy link
Member

javanna commented May 10, 2014

Closing since what was asked is not viable using snapshot/restore api, as expained above.

@javanna javanna closed this as completed May 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants