Put Mappingedit

The PUT mapping API allows you to add a new type to an existing index, or new fields to an existing type:

PUT twitter 
{
  "mappings": {
    "tweet": {
      "properties": {
        "message": {
          "type": "string"
        }
      }
    }
  }
}

PUT twitter/_mapping/user 
{
  "properties": {
    "name": {
      "type": "string"
    }
  }
}

PUT twitter/_mapping/tweet 
{
  "properties": {
    "user_name": {
      "type": "string"
    }
  }
}

Creates an index called twitter with the message field in the tweet mapping type.

Uses the PUT mapping API to add a new mapping type called user.

Uses the PUT mapping API to add a new field called user_name to the tweet mapping type.

More information on how to define type mappings can be found in the mapping section.

Multi-indexedit

The PUT mapping API can be applied to multiple indices with a single request. It has the following format:

PUT /{index}/_mapping/{type}
{ body }
  • {index} accepts multiple index names and wildcards.
  • {type} is the name of the type to update.
  • {body} contains the mapping changes that should be applied.

Updating field mappingsedit

In general, the mapping for existing fields cannot be updated. There are some exceptions to this rule. For instance:

For example:

PUT my_index 
{
  "mappings": {
    "user": {
      "properties": {
        "name": {
          "properties": {
            "first": {
              "type": "string"
            }
          }
        },
        "user_id": {
          "type": "string",
          "index": "not_analyzed"
        }
      }
    }
  }
}

PUT my_index/_mapping/user
{
  "properties": {
    "name": {
      "properties": {
        "last": { 
          "type": "string"
        }
      }
    },
    "user_id": {
      "type": "string",
      "index": "not_analyzed",
      "ignore_above": 100 
    }
  }
}

Create an index with a first field under the name Object datatype field, and a user_id field.

Add a last field under the name object field.

Update the ignore_above setting from its default of 0.

Each mapping parameter specifies whether or not its setting can be updated on an existing field.

Conflicts between fields in different typesedit

Fields in the same index with the same name in two different types must have the same mapping, as they are backed by the same field internally. Trying to update a mapping parameter for a field which exists in more than one type will throw an exception, unless you specify the update_all_types parameter, in which case it will update that parameter across all fields with the same name in the same index.

The only parameters which are exempt from this rule — they can be set to different values on each field — can be found in Fields are shared across mapping types.

For example:

PUT my_index
{
  "mappings": {
    "type_one": {
      "properties": {
        "text": { 
          "type": "string",
          "analyzer": "standard"
        }
      }
    },
    "type_two": {
      "properties": {
        "text": { 
          "type": "string",
          "analyzer": "standard"
        }
      }
    }
  }
}

PUT my_index/_mapping/type_one 
{
  "properties": {
    "text": {
      "type": "string",
      "analyzer": "standard",
      "search_analyzer": "whitespace"
    }
  }
}

PUT my_index/_mapping/type_one?update_all_types 
{
  "properties": {
    "text": {
      "type": "string",
      "analyzer": "standard",
      "search_analyzer": "whitespace"
    }
  }
}

Create an index with two types, both of which contain a text field which have the same mapping.

Trying to update the search_analyzer just for type_one throws an exception like "Merge failed with failures...".

Adding the update_all_types parameter updates the text field in type_one and type_two.