# Dynamic template for parent child mapping

**URL:** https://discuss.elastic.co/t/dynamic-template-for-parent-child-mapping/128181
**Category:** Elasticsearch
**Created:** [April 16, 2018, 11:41am UTC](https://discuss.elastic.co/t/dynamic-template-for-parent-child-mapping/128181 "2018-04-16T11:41:04Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![manik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/manik/32/30026_2.png) [@manik](https://discuss.elastic.co/u/manik)
#### Post date: [April 16, 2018, 11:41am UTC](https://discuss.elastic.co/t/dynamic-template-for-parent-child-mapping/128181/1 "2018-04-16T11:41:04Z")

</div>

I'm using Elastic search 2.4.6 version. I want to have parent child relationship in my document. Parent is product related attributes and child is parent-city related attributes. We've around 100 cities now. Our idea is Product related attributes is Parent type and each city/product related attributes in product\_{city}. So 100 types. Is there anyway to define this mapping dynamically like this ?

```
  {
        "mappings": {
            "product": {},
            "product_*": {
                "_parent": {
                    "type": "product"
                }
            }
        }
    } 

```

So that when we add new city, I don't have to delete and recreate the index again ?

---

<div class="post-metadata">

### Author: ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [April 16, 2018, 7:25pm UTC](https://discuss.elastic.co/t/dynamic-template-for-parent-child-mapping/128181/2 "2018-04-16T19:25:00Z")

</div>

> So 100 types

I cannot think of a good way to solve this issue, but I just want to warn you that this approach is not sustainable in a long run. It is not efficient and the current version of elasticsearch doesn't support more than 1 type per index. So, I would recommend going with just 2 types - one for product and another for attribute. And if you are developing a new system, I would strongly advise to go with a more modern version of ES since the handling of parent child relationships and types changed dramatically recently.

---

<div class="post-metadata">

### Author: ![manik](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/manik/32/30026_2.png) [@manik](https://discuss.elastic.co/u/manik)
#### Post date: [April 17, 2018, 4:29am UTC](https://discuss.elastic.co/t/dynamic-template-for-parent-child-mapping/128181/3 "2018-04-17T04:29:44Z")

</div>

Thanks for the response. Our main reason to have 100 types is to have smaller set for search. Our search is always at single city level. We'll try to have to single type and see how that affects the performance.

---

<div class="post-metadata">

### Author: ![Igor\_Motov](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/igor_motov/32/45193_2.png) [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [April 17, 2018, 1:06pm UTC](https://discuss.elastic.co/t/dynamic-template-for-parent-child-mapping/128181/4 "2018-04-17T13:06:49Z")

</div>

Internally searching a type is implemented as a [term](https://www.elastic.co/guide/en/elasticsearch/reference/2.4/query-dsl-term-query.html) query on the internal field `_type`. This query is automatically added to your search when you search within a type. If you add a not analyzed field called `type` and add your own term query to your search, you will get the same performance benefits during search, but you will save time maintaining and shipping around a huge mapping in the cluster state.

---

<div class="post-metadata">

### Author: ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)
#### Post date: [May 15, 2018, 1:06pm UTC](https://discuss.elastic.co/t/dynamic-template-for-parent-child-mapping/128181/5 "2018-05-15T13:06:52Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
