# Documentation for dynamic template mappings?

**URL:** https://discuss.elastic.co/t/documentation-for-dynamic-template-mappings/311746
**Category:** Elasticsearch
**Created:** [August 9, 2022, 2:18pm UTC](https://discuss.elastic.co/t/documentation-for-dynamic-template-mappings/311746 "2022-08-09T14:18:27Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![nisow95612](https://avatars.discourse-cdn.com/v4/letter/n/3d9bf3/32.png) [@nisow95612](https://discuss.elastic.co/u/nisow95612)
#### Post date: [August 10, 2022, 8:59am UTC](https://discuss.elastic.co/t/documentation-for-dynamic-template-mappings/311746/3 "2022-08-10T08:59:43Z")

</div>

Thanks for answering this quickly.

Yes, I am specifically looking for a more complete description of this `dynamic mapping templates` feature.  
The best I managed to find is [Dynamic templates | Elasticsearch Guide [8.3] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/dynamic-templates.html#dynamic-templates), but it looks incomplete. For example it claims that `Dynamic templates are specified as an array of named objects:` like this:

```auto
"dynamic_templates": [
    {
      "my_template_name": { 
        ... match conditions ... 
        "mapping": { ... } 
      }
    },

```

But actually the `"mapping"` part is not mandatory at all. On the other hand there could be a `"runtime"` section that is not mentioned in the syntax (and its presence actually forbids `"mapping"` from being present). I am looking for details like this.

* * *

Well, concretely I am trying to ossify/formalize the currently known mappings without losing the agility of a fresh _ES_ installation when it comes to processing of previously unknown fields.  
I do not like `"dynamic": "enabled"`, because that does not provide an easy way for _kibana_ users to see that a field is prone to conflicts and/or changes because its type is not fixed.  
I also do not like `"dynamic":"runtime"`, because that does not provide adequate performance. The moment the users of the _kibana_ notice the new field, they will expect full performace of it.

* * *

A perfect solution would be to have `"dynamic": "enabled"` but somehow mark the dynamically added fields in a way that alerts users of _kibana_ that this field is not set in stone and may change.

For example I hoped to create a subfield _"fieldname.autodetected"_ and prevent the _"fieldname"_ field from being mapped at all (like [Mapping: trying to ignore 'field' but keeping 'field.raw'](https://discuss.elastic.co/t/mapping-trying-to-ignore-field-but-keeping-field-raw/92621) asks), but found no way to do that. I know I can make the _"fieldname"_ field unindexed, but that will both confuse the users AND occupy two slots out of the 1000-field-limit instead of one.

I could tolerate the _"fieldname"_ field being a runtime field and _"fieldname.autodetected"_ being a normal field, but I do not see any example for this either.

Thus, I was hoping somebody could point me to a more complete documentation where I could find these things.

---

_[View the full topic](https://discuss.elastic.co/t/documentation-for-dynamic-template-mappings/311746)._