The field can be used in different contexts, in place of the target field. However, there are some restrictions to keep in mind. Let’s list them.
The path must indicate an existent, concrete field
The target field of an alias cannot be an object, an array or another field alias, including the field itself: it must be a concrete field.
In addition, it can’t be a dynamic field (i.e. a field whose name has been declared with wildcards in the dynamic_templates section) because the alias binding is done at mapping time. As a consequence of that, the target field must exist when the alias is created. The following request:
will return a 400 error with the following message:
Invalid [path] value [creation_date] for field alias [headings]: an alias must refer to an existing field in the mappings
An alias can't have multiple target fields
That means the value of the path attribute cannot be an array, only a single value. In other words, it’s not possible to have a single field that aliases multiple fields. The following request:
will return a 400 error with the following message:
Invalid [path] value [[title, author]] for field alias [headings]: an alias must refer to an existing field in the mappings
which I could agree with you, that doesn’t really indicate the real problem. That is because the whole value of the path attribute is interpreted as a field name, and “[[title, author]]” doesn’t correspond to a field.
Target field cannot be an alias
This means that we cannot indicate an alias field in the path attribute:
a request like the above will return the following error:
Invalid [path] value [another_field_whose_type_is_alias] for field alias [headings]: an alias cannot refer to another alias
other than the example above, under the same rule we should mention:
an alias field cannot be used in the copy_to directive
an alias field cannot be used as a type of a multi-field
The reason is the same for both points above: the alias field doesn’t exist, it’s virtual, so it cannot be used as a destination for a value coming from another field, as it happens in multi-fields or in the copy_to directive.
The following definitions are invalid:
{
"properties": {
"title": {
"type": "text",
"copy_to": "alias_field"
},
"alias_field": {
"type": "alias",
"path": <some other field, even a concrete one>
}
}
}
This is actually a rule that is valid for all fields. The dot character has a special meaning in elasticsearch: it is used for defining derived fields (called multi-fields) that are created on top of a parent field definition, as in the following example:
The configuration above will create three different fields:
title: the parent field. It is associated with a standard analyzer
title.en: a derived field which will inherits the value from the parent field. The value will be processed using a symmetric (i.e. index and query time) english analyzer
title.it: a derived field which will inherits the value from the parent field. The value will be processed using a symmetric (i.e. index and query time) italian analyzer
So in the definition above, the value assigned to the parent field will be used also for creating the derived fields.
Can a field name contain a dot? The answer is “it depends”.
Specifically, if the part before the dot denotes another existing field, then answer is negative, because Elasticsearch will interpret it as a de-touched multi-field. The following request:
An alias can't be used in input documents (i.e. indexing)
Being virtual fields, input documents (i.e. documents sent to Elasticsearch for indexing) cannotcontain alias fields: they must indicate only concrete fields.
Aliases cannot be used in source filtering
Remember: alias fields are virtual, they are not part of the source document, and as a consequence of that:
they won’t appear within the _source element in responses
Did you like this post about the Elasticsearch Alias Field Type? Don’t forget to subscribe to our Newsletter to stay always updated from the Information Retrieval world!
Related
Author
Andrea Gazzarini
Andrea Gazzarini is a curious software engineer, mainly focused on the Java language and Search technologies.
With more than 15 years of experience in various software engineering areas, his adventure in the search world began in 2010, when he met Apache Solr and later Elasticsearch.