[[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/_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 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.