82 lines
2.7 KiB
Plaintext
82 lines
2.7 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
|
|
definition can be overridden in several manners. The simplest manner is
|
|
to simply define a file called `default-mapping.json` and to place it
|
|
under the `config` directory (which can be configured to exist in a
|
|
different location). It can also be explicitly set using the
|
|
`index.mapper.default_mapping_location` setting.
|
|
|
|
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/tweet/_mapping' -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
|
|
|
|
coming[1.4.0]
|
|
|
|
Queries and filters can refer to fields which don't exist in a mapping, except
|
|
when registering a new <<search-percolate,percolator query>> or when creating
|
|
a <<filtered,filtered alias>>. In these two cases, any fields referred to in
|
|
the query or filter must already exist in the mapping, otherwise there is a
|
|
chance that the wrong field type will be used.
|
|
|
|
This requirement can be disabled by setting
|
|
`index.query.parse.allow_unmapped_fields` to `true`, in which case you run the
|
|
risk that your query or filter might not work correctly.
|
|
|