73 lines
2.4 KiB
Plaintext
73 lines
2.4 KiB
Plaintext
[[mapping-dynamic-mapping]]
|
|
== Dynamic Mapping
|
|
|
|
Default mappings allow generic mapping definitions to be automatically applied
|
|
to types that do not have mappings predefined. This is mainly done
|
|
thanks to the fact that the
|
|
<<mapping-object-type,object mapping>> and
|
|
namely the <<mapping-root-object-type,root
|
|
object mapping>> allow for schema-less dynamic addition of unmapped
|
|
fields.
|
|
|
|
The default mapping definition is a plain mapping definition that is
|
|
embedded within the distribution:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
"_default_" : {
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
|
|
Pretty short, isn't it? Basically, everything is defaulted, especially the
|
|
dynamic nature of the root object mapping. The default mapping can be
|
|
overridden by specifying the `_default_` type when creating a new index.
|
|
|
|
The dynamic creation of mappings for unmapped types can be completely
|
|
disabled by setting `index.mapper.dynamic` to `false`.
|
|
|
|
The dynamic creation of fields within a type can be completely
|
|
disabled by setting the `dynamic` property of the type to `strict`.
|
|
|
|
Here is a <<indices-put-mapping,Put Mapping>> example that
|
|
disables dynamic field creation for a `tweet`:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
$ curl -XPUT 'http://localhost:9200/twitter/_mapping/tweet' -d '
|
|
{
|
|
"tweet" : {
|
|
"dynamic": "strict",
|
|
"properties" : {
|
|
"message" : {"type" : "string", "store" : true }
|
|
}
|
|
}
|
|
}
|
|
'
|
|
--------------------------------------------------
|
|
|
|
Here is how we can change the default
|
|
<<mapping-date-format,date_formats>> used in the
|
|
root and inner object types:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
"_default_" : {
|
|
"dynamic_date_formats" : ["yyyy-MM-dd", "dd-MM-yyyy", "date_optional_time"]
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
|
|
[float]
|
|
=== Unmapped fields in queries
|
|
|
|
Queries and filters can refer to fields that don't exist in a mapping. Whether this
|
|
is allowed is controlled by the `index.query.parse.allow_unmapped_fields` setting.
|
|
This setting defaults to `true`. Setting it to `false` will disallow the usage of
|
|
unmapped fields in queries.
|
|
|
|
When registering a new <<search-percolate,percolator query>> or creating
|
|
a <<filtered,filtered alias>> then the `index.query.parse.allow_unmapped_fields` setting
|
|
is forcefully overwritten to disallowed unmapped fields. |