By default, when a previously unseen field is found in a document,
Elasticsearch will add the new field to the type mapping. This behaviour can
be disabled, both at the document and at the object
level, by
setting the dynamic
parameter to false
(to ignore new fields) or to strict
(to throw
an exception if an unknown field is encountered).
Assuming dynamic
field mapping is enabled, some simple rules are used to
determine which datatype the field should have:
JSON datatype |
Elasticsearch datatype |
|
No field is added. |
|
|
floating point number |
|
integer |
|
object |
|
array |
Depends on the first non- |
string |
Either a |
These are the only field datatypes that are dynamically detected. All other datatypes must be mapped explicitly.
Besides the options listed below, dynamic field mapping rules can be further
customised with dynamic_templates
.
If date_detection
is enabled (default), then new string fields are checked
to see whether their contents match any of the date patterns specified in
dynamic_date_formats
. If a match is found, a new date
field is
added with the corresponding format.
The default value for dynamic_date_formats
is:
[ "strict_date_optional_time"
,"yyyy/MM/dd HH:mm:ss Z||yyyy/MM/dd Z"
]
For example:
The |
Dynamic date detection can be disabled by setting date_detection
to false
:
PUT my_index { "mappings": { "date_detection": false } } PUT my_index/_doc/1 { "create": "2015/09/02" }
The |
Alternatively, the dynamic_date_formats
can be customised to support your
own date formats:
PUT my_index { "mappings": { "dynamic_date_formats": ["MM/dd/yyyy"] } } PUT my_index/_doc/1 { "create_date": "09/25/2015" }
While JSON has support for native floating point and integer datatypes, some applications or languages may sometimes render numbers as strings. Usually the correct solution is to map these fields explicitly, but numeric detection (which is disabled by default) can be enabled to do this automatically: