OpenSearch/docs/reference/mapping/dynamic-mapping.asciidoc

73 lines
2.4 KiB
Plaintext
Raw Normal View History

[[mapping-dynamic-mapping]]
== Dynamic Mapping
2014-05-20 07:33:53 -04:00
Default mappings allow generic mapping definitions to be automatically applied
2014-03-07 08:21:45 -05:00
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.
2014-03-07 08:21:45 -05:00
The default mapping definition is a plain mapping definition that is
embedded within the distribution:
[source,js]
--------------------------------------------------
{
"_default_" : {
}
}
--------------------------------------------------
2014-03-07 08:21:45 -05:00
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`.
2013-10-10 14:17:49 -04:00
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 '
2013-10-10 14:17:49 -04:00
{
"tweet" : {
"dynamic": "strict",
"properties" : {
"message" : {"type" : "string", "store" : true }
2013-10-10 14:17:49 -04:00
}
}
}
'
--------------------------------------------------
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.