ElasticSearch Cookbook
上QQ阅读APP看书,第一时间看更新

Using dynamic templates in document mapping

In the Using explicit mapping creation recipe, we saw how ElasticSearch is able to guess the field type using reflection. In this recipe we'll see how to help improve its guessing capabilities.

Getting ready

You need a working ElasticSearch cluster.

How to do it...

We can extend the previous mapping adding document-related settings:

{
  "order" : {
    "index_analyzer":"standard",
    "search_analyzer":"standard",
    "dynamic_date_formats":["yyyy-MM-dd", "dd-MM-yyyy"],
    "date_detection":true,
    "numeric_detection":true,
    "dynamic_templates":[
    {"template1":{      "match":"*",      "match_mapping_type":"long",      "mapping":{"type":" {dynamic_type}",       "store":true}    }}
    ],    "properties" : {…}
  }
}

How it works...

The root object (document) controls the behavior of its fields and all its children object fields.

In the document mapping we can define:

  • index_analyzer: This defines the analyzer to be used for indexing within this document. If index_analyzer is not defined in a field, this is considered as default.
  • search_analyzer: This defines the analyzer to be used for searching. If a field doesn't define an analyzer, search_analyzer of the document, if available, is taken.

    Tip

    If you need to set index_analyzer and search_analyzer with the same value, you can use the analyzer property.

  • date_detection (defaults to true): This enables the extraction of a date from a string.
  • dynamic_date_formats: This is a list of valid date formats. It is used if date_detection is active.
  • numeric_detection (defaults to false): This enables the conversion of strings to numbers if it is possible.
  • dynamic_templates: This list of templates is used to change the explicit mapping. If one of these templates is matched, the rules defined in it are used to build the final mapping.

A dynamic template is composed of two parts: the matcher and the mapping one.

To match a field for activating the template, several types of matchers are available, such as:

  • match: This allows defining a match on the field name. The expression is a standard GLOB.
  • unmatch (optional): This allows defining the expression to be used to exclude matches.
  • match_mapping_type (optional): This controls the type of matched fields. For example, string, integer, and so on.
  • path_match (optional): This allows matching the dynamic template against the full dot notation of the field. For example, obj1.*.value.
  • path_unmatch (optional): This does the opposite of path_match, excluding the matched fields.
  • match_pattern (optional): This allows switching the matchers to regex (regular expression); otherwise, the glob pattern match is used.

The dynamic template mapping part is a standard one, but with the ability to use special placeholders such as:

  • {name}: This will be replaced with the actual dynamic field name
  • {dynamic_type}: This will be replaced with the type of the matched field

    Tip

    The order of dynamic templates is very important, only the first one that is matched is executed. It is good practice to order first the ones with more strict rules and then the other ones.

There's more...

The dynamic template is very handy when you need to set a mapping configuration to all the fields. This action can be done by adding a dynamic template similar to the following code snippet:

"dynamic_templates" : [
  {
    "store_generic" : {
      "match" : "*",
      "mapping" : {
        "store" : "yes"
      }
    }
  }
] 

In this example, all the new fields, which will be added with the explicit mapping, will be stored.

See also