Alias field type

An alias mapping defines an alternate name for a field in the index. The alias can be used in place of the target field in search requests, and selected other APIs like field capabilities.

  1. PUT trips
  2. {
  3.   "mappings": {
  4.     "properties": {
  5.       "distance": {
  6.         "type": "long"
  7.       },
  8.       "route_length_miles": {
  9.         "type": "alias",
  10.         "path": "distance" 
  11.       },
  12.       "transit_mode": {
  13.         "type": "keyword"
  14.       }
  15.     }
  16.   }
  17. }
  19. GET _search
  20. {
  21.   "query": {
  22.     "range" : {
  23.       "route_length_miles" : {
  24.         "gte" : 39
  25.       }
  26.     }
  27.   }
  28. }

The path to the target field. Note that this must be the full path, including any parent objects (e.g. object1.object2.field).

Almost all components of the search request accept field aliases. In particular, aliases can be used in queries, aggregations, and sort fields, as well as when requesting docvalue_fields, stored_fields, suggestions, and highlights. Scripts also support aliases when accessing field values. Please see the section on unsupported APIs for exceptions.

In some parts of the search request and when requesting field capabilities, field wildcard patterns can be provided. In these cases, the wildcard pattern will match field aliases in addition to concrete fields:

  1. GET trips/_field_caps?fields=route_*,transit_mode

Alias targets

There are a few restrictions on the target of an alias:

  • The target must be a concrete field, and not an object or another field alias.
  • The target field must exist at the time the alias is created.
  • If nested objects are defined, a field alias must have the same nested scope as its target.

Additionally, a field alias can only have one target. This means that it is not possible to use a field alias to query over multiple target fields in a single clause.

An alias can be changed to refer to a new target through a mappings update. A known limitation is that if any stored percolator queries contain the field alias, they will still refer to its original target. More information can be found in the percolator documentation.

Unsupported APIs

Writes to field aliases are not supported: attempting to use an alias in an index or update request will result in a failure. Likewise, aliases cannot be used as the target of copy_to or in multi-fields.

Because alias names are not present in the document source, aliases cannot be used when performing source filtering. For example, the following request will return an empty result for _source:

  1. GET /_search
  2. {
  3.   "query" : {
  4.     "match_all": {}
  5.   },
  6.   "_source": "route_length_miles"
  7. }

Currently only the search and field capabilities APIs will accept and resolve field aliases. Other APIs that accept field names, such as term vectors, cannot be used with field aliases.

Finally, some queries, such as terms, geo_shape, and more_like_this, allow for fetching query information from an indexed document. Because field aliases aren’t supported when fetching documents, the part of the query that specifies the lookup path cannot refer to a field by its alias.