# Mapping with allow\_malformed doesn't seem to be applied

**URL:** <https://discuss.elastic.co/t/mapping-with-allow-malformed-doesnt-seem-to-be-applied/208320>\
**Category:** Elasticsearch\
**Created:** [November 18, 2019, 1:55pm UTC](https://discuss.elastic.co/t/mapping-with-allow-malformed-doesnt-seem-to-be-applied/208320 "2019-11-18T13:55:12Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![aspyct](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aspyct/32/45911_2.png) [@aspyct](https://discuss.elastic.co/u/aspyct)\
**Post date:** [November 18, 2019, 1:55pm UTC](https://discuss.elastic.co/t/mapping-with-allow-malformed-doesnt-seem-to-be-applied/208320/1 "2019-11-18T13:55:13Z")

</div>

Hi,

The mapping on my index doesn't seem to be respected. One of the properties, `bytes_read` is defined as an integer in the mapping. But I have also enabled `allow_malformed` in the index settings, in the hope of salvaging data that doesn't fit the mapping.

This is (a part of) the index effective mapping, as reported in kibana (Settings \> Index Management \> Mapping)

```
{
  "mapping": {
    "properties": {
      "bytes_read": {
        "type": "integer"
      }
    }
  }
}

```

And (a part of) the index settings:

```
{
  "settings": {
    "index": {
      "mapping": {
        "ignore_malformed": "true"
      }
    }
  }
}

```

A new index is created everyday. The mapping is consistent throughout the indices, but the value of `bytes_read` is still mapped as a string, according to kibana:

![14](https://us1.discourse-cdn.com/elastic/original/3X/3/6/36030363606845960489ba7ed17d39b85478760b.png)

Also, I can't search or use it like a number anyway. Older indices didn't have the correct mapping, and probably assigned the type string/keyword to `bytes_read`, but it should now be fixed.

tldr: Why is my `bytes_read` not stored as an integer?

---

<div class="post-metadata">

**Author:** ![Glen\_Smith](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/glen_smith/32/111656_2.png) [@Glen\_Smith](https://discuss.elastic.co/u/Glen_Smith)\
**Post date:** [November 18, 2019, 7:07pm UTC](https://discuss.elastic.co/t/mapping-with-allow-malformed-doesnt-seem-to-be-applied/208320/2 "2019-11-18T19:07:02Z")

</div>

If you want string delimited numeric values to be indexed as numerics, try using [the coerce setting](https://www.elastic.co/guide/en/elasticsearch/reference/current/coerce.html).

---

<div class="post-metadata">

**Author:** ![aspyct](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aspyct/32/45911_2.png) [@aspyct](https://discuss.elastic.co/u/aspyct)\
**Post date:** [November 19, 2019, 6:26am UTC](https://discuss.elastic.co/t/mapping-with-allow-malformed-doesnt-seem-to-be-applied/208320/3 "2019-11-19T06:26:27Z")

</div>

What are you referring to by "string delimited numeric values"?

I've just checked in our development cluster, with the same mapping and same "allow\_malformed" settings, `bytes_read` is properly parsed as an integer, even though I don't have that coerce setting set. Surely it must be something else I overlooked.

---

<div class="post-metadata">

**Author:** ![aspyct](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/aspyct/32/45911_2.png) [@aspyct](https://discuss.elastic.co/u/aspyct)\
**Post date:** [November 19, 2019, 9:54am UTC](https://discuss.elastic.co/t/mapping-with-allow-malformed-doesnt-seem-to-be-applied/208320/4 "2019-11-19T09:54:09Z")

</div>

It turns out I had to refresh the index pattern in kibana for it to notice the new data type. I'm left with data type conflicts now, which renders search unusable. Apparently reindexing can solve the issue.

---

<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:** [December 17, 2019, 9:54am UTC](https://discuss.elastic.co/t/mapping-with-allow-malformed-doesnt-seem-to-be-applied/208320/5 "2019-12-17T09:54:17Z")

</div>

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