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

90 lines
2.8 KiB
Plaintext
Raw Normal View History

[[dynamic]]
=== `dynamic`
By default, fields can be added _dynamically_ to a document, or to
<<object,inner objects>> within a document, just by indexing a document
containing the new field. For instance:
[source,js]
--------------------------------------------------
PUT my_index/_doc/1 <1>
{
"username": "johnsmith",
"name": {
"first": "John",
"last": "Smith"
}
}
GET my_index/_mapping <2>
PUT my_index/_doc/2 <3>
{
"username": "marywhite",
"email": "mary@white.com",
"name": {
"first": "Mary",
"middle": "Alice",
"last": "White"
}
}
GET my_index/_mapping <4>
--------------------------------------------------
// CONSOLE
<1> This document introduces the string field `username`, the object field
`name`, and two string fields under the `name` object which can be
referred to as `name.first` and `name.last`.
<2> Check the mapping to verify the above.
<3> This document adds two string fields: `email` and `name.middle`.
<4> Check the mapping to verify the changes.
The details of how new fields are detected and added to the mapping is explained in <<dynamic-mapping>>.
The `dynamic` setting controls whether new fields can be added dynamically or
not. It accepts three settings:
[horizontal]
`true`:: Newly detected fields are added to the mapping. (default)
`false`:: Newly detected fields are ignored. These fields will not be indexed so will not be searchable
but will still appear in the `_source` field of returned hits. These fields will not be added
to the mapping, new fields must be added explicitly.
`strict`:: If new fields are detected, an exception is thrown and the document is rejected. New fields
must be explicitly added to the mapping.
The `dynamic` setting may be set at the mapping type level, and on each
<<object,inner object>>. Inner objects inherit the setting from their parent
object or from the mapping type. For instance:
[source,js]
--------------------------------------------------
Update the default for include_type_name to false. (#37285) * Default include_type_name to false for get and put mappings. * Default include_type_name to false for get field mappings. * Add a constant for the default include_type_name value. * Default include_type_name to false for get and put index templates. * Default include_type_name to false for create index. * Update create index calls in REST documentation to use include_type_name=true. * Some minor clean-ups around the get index API. * In REST tests, use include_type_name=true by default for index creation. * Make sure to use 'expression == false'. * Clarify the different IndexTemplateMetaData toXContent methods. * Fix FullClusterRestartIT#testSnapshotRestore. * Fix the ml_anomalies_default_mappings test. * Fix GetFieldMappingsResponseTests and GetIndexTemplateResponseTests. We make sure to specify include_type_name=true during xContent parsing, so we continue to test the legacy typed responses. XContent generation for the typeless responses is currently only covered by REST tests, but we will be adding unit test coverage for these as we implement each typeless API in the Java HLRC. This commit also refactors GetMappingsResponse to follow the same appraoch as the other mappings-related responses, where we read include_type_name out of the xContent params, instead of creating a second toXContent method. This gives better consistency in the response parsing code. * Fix more REST tests. * Improve some wording in the create index documentation. * Add a note about types removal in the create index docs. * Fix SmokeTestMonitoringWithSecurityIT#testHTTPExporterWithSSL. * Make sure to mention include_type_name in the REST docs for affected APIs. * Make sure to use 'expression == false' in FullClusterRestartIT. * Mention include_type_name in the REST templates docs.
2019-01-14 16:08:01 -05:00
PUT my_index?include_type_name=true
{
"mappings": {
"_doc": {
"dynamic": false, <1>
"properties": {
"user": { <2>
"properties": {
"name": {
2016-03-18 12:01:27 -04:00
"type": "text"
},
"social_networks": { <3>
"dynamic": true,
"properties": {}
}
}
}
}
}
}
}
--------------------------------------------------
// CONSOLE
<1> Dynamic mapping is disabled at the type level, so no new top-level fields will be added dynamically.
<2> The `user` object inherits the type-level setting.
<3> The `user.social_networks` object enables dynamic mapping, so new fields may be added to this inner object.
TIP: The `dynamic` setting can be updated on existing fields
using the <<indices-put-mapping,PUT mapping API>>.