# Dots in Fieldnames =\> ES 2.X Upgrade will fail?

**URL:** <https://discuss.elastic.co/t/dots-in-fieldnames-es-2-x-upgrade-will-fail/56069>\
**Category:** Elasticsearch\
**Created:** [July 21, 2016, 7:52am UTC](https://discuss.elastic.co/t/dots-in-fieldnames-es-2-x-upgrade-will-fail/56069 "2016-07-21T07:52:08Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![german23](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/german23/32/11052_2.png) [@german23](https://discuss.elastic.co/u/german23)\
**Post date:** [July 21, 2016, 7:52am UTC](https://discuss.elastic.co/t/dots-in-fieldnames-es-2-x-upgrade-will-fail/56069/1 "2016-07-21T07:52:08Z")

</div>

Hi guys,

i apologize if this is 1242032nd thread to this particular upgrade topic.

After getting rid of the different mapping-types of fields in different ES-types, i now got the "problem" to have some fields with dots in it in almost every index, mostly completely nonsense fields that got produced by an not 100% working Logstashfilter.

Migration-Tool is telling me after the last Update that it is a big issue, however a long time it displayed the "dot-fields" as a yellow error - meaning it is not optimal and those fields wont continue to work in ES2.0.

When i upgrade my ES 1.7 to 2.1 or 2.3, will the upgrade process fails cause of this annoying fields or will there be a warning displayed?

If it fails, why? Seems like ES 2.0 can deal with dot fields, as it does e.g. with the ".raw" multi fields.

It would be a work of months to reindex all of the indices, so i hope i could get around it 🙂

Thanks for your response.

---

<div class="post-metadata">

**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\
**Post date:** [July 21, 2016, 6:41pm UTC](https://discuss.elastic.co/t/dots-in-fieldnames-es-2-x-upgrade-will-fail/56069/2 "2016-07-21T18:41:56Z")

</div>

You can not get around it. ES uses dots as internal field name separators.

ES 1 produced an inconsistency between

```auto
"a" : {
  "b" : "c"
}

```

and

```auto
"a.b" : "c"

```

and

```auto
"b" : "c"

```

when referencing field name `a.b` or short form `b` in a query.

ES2 resolves this to the former case and enforces full field names in the mapping.

---

<div class="post-metadata">

**Author:** ![german23](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/german23/32/11052_2.png) [@german23](https://discuss.elastic.co/u/german23)\
**Post date:** [July 22, 2016, 5:18am UTC](https://discuss.elastic.co/t/dots-in-fieldnames-es-2-x-upgrade-will-fail/56069/3 "2016-07-22T05:18:17Z")

</div>

Thanks for your detailed answer.

Too bad ES dont just ignore that inconsistent fields on upgrade/mapping.

But it wont help than, sigh

---

<div class="post-metadata">

**Author:** ![ndtreviv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ndtreviv/32/22494_2.png) [@ndtreviv](https://discuss.elastic.co/u/ndtreviv)\
**Post date:** [July 28, 2016, 9:01am UTC](https://discuss.elastic.co/t/dots-in-fieldnames-es-2-x-upgrade-will-fail/56069/4 "2016-07-28T09:01:19Z")

</div>

What I would LOVE is an option to replace the dots in fields upon snapshot restore/upgrade.

At the moment I'm having to write a program to go through and re-index all documents using fields without dots so that we can later upgrade.

This makes me sad, especially when: [http://stackoverflow.com/questions/38615227/elasticsearch-allows-duplicate-id-with-different-body-data](http://stackoverflow.com/questions/38615227/elasticsearch-allows-duplicate-id-with-different-body-data)

---

<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:** [July 5, 2017, 10:32pm UTC](https://discuss.elastic.co/t/dots-in-fieldnames-es-2-x-upgrade-will-fail/56069/5 "2017-07-05T22:32:14Z")

</div>