How do dynamic_templates control the types Elasticsearch assigns to newly seen fields?

## The problem they solve Explicit mappings are exact but require you to know every field name in advance. Dynamic mapping needs no foreknowledge but produces whatever its inference rules produce. `dynamic_templates` sit in between: you cannot name the fields, but you can state a rule about *shape* — "every string under `labels.*` is a keyword", "every double is stored but not indexed" — and have it applied to fields you have never seen. ## Structure The mapping holds an **array**, and each element is an object with exactly one key: the template's name, which exists only for readability and for the error messages. ```json "dynamic_templates": [ { "strings_as_keyword": { "match_mapping_type": "string", "mapping": { "type": "keyword", "ignore_above": 256 } }}, { "metrics_as_double": { "path_match": "metrics.*", "match_mapping_type": "long", "mapping": { "type": "double" } }} ] ``` Order matters and is the most common source of confusion: evaluation stops at the first template whose predicates all match, so a broad `match_mapping_type: "*"` rule placed first makes everything after it dead code. Put the specific rules first. ## The predicates - **`match_mapping_type`** matches the type dynamic detection *would* have chosen: `string`, `long`, `double`, `boolean`, `date`, `object`, or `*` for any. Note that this is the detected JSON-level type, so an unquoted whole number is `long` and a fractional one is `double`, regardless of what you want the final field to be. - **`match` / `unmatch`** test the field's own (leaf) name, with `*` wildcards — `"match": "*_id"`. - **`path_match` / `path_unmatch`** test the full dotted path, so `"path_match": "user.social.*"` targets a subtree rather than a name pattern. - **`match_pattern: "regex"`** switches `match`/`unmatch` from glob to Java regular expressions. When several predicates are present they are ANDed. Predicates can also be supplied as arrays of patterns to match any of several shapes. ## The mapping block and its placeholders The `mapping` value is an ordinary field definition — anything you could have written under `properties`, including multi-fields, `index: false`, `ignore_above`, `null_value`, analyzers, and so on. Two placeholders are substituted: - `{name}` — the field's name, useful for `"copy_to": "{name}_all"`-style constructions and for naming analyzers per field; - `{dynamic_type}` — the detected type, which lets one template say "whatever type you detected, but with doc values off". A template may also declare a `runtime` block instead of `mapping`, mapping matching fields as runtime fields rather than indexed ones — a middle ground between `dynamic: true` and `dynamic: runtime` that applies only to the shapes you choose. ## What they are used for in practice **Killing the text/keyword pair.** For logs and metrics you almost never need full-text analysis on arbitrary string fields, and each such field otherwise costs two mapping entries plus an analysed index. One `match_mapping_type: "string" → keyword` template is the single highest-value template most clusters have. **Type correction by convention.** `*_id` as `keyword`, `*_at` as `date`, `is_*` as `boolean` — a naming convention becomes a schema without enumerating fields. **Turning off what you do not query.** `index: false` on a bulky subtree keeps values retrievable through `_source` while cutting index size; `doc_values: false` on fields you never sort or aggregate saves disk. ## Limits worth knowing Templates apply only to fields that are **not** already mapped, and only when the effective `dynamic` value permits new fields at all — with `dynamic: strict` nothing is dynamically added, so no template will ever fire. They do not retroactively change fields that were mapped before the template existed; that still means a reindex. And they still do not cap *how many* fields appear — a template can dictate that every new key is a keyword while the number of keys grows without bound, which is a separate problem with a separate control. Because they are part of the mapping, templates are normally shipped in an index template so every new index (or data-stream backing index) is born with the house rules already in place, rather than being retrofitted after the first bad field has landed.