# Dynamic mapping: Confusing type inference behaviour

**URL:** https://discuss.elastic.co/t/dynamic-mapping-confusing-type-inference-behaviour/197371
**Category:** Elasticsearch
**Created:** [August 29, 2019, 2:53pm UTC](https://discuss.elastic.co/t/dynamic-mapping-confusing-type-inference-behaviour/197371 "2019-08-29T14:53:58Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![timost](https://avatars.discourse-cdn.com/v4/letter/t/e95f7d/32.png) [@timost](https://discuss.elastic.co/u/timost)
#### Post date: [August 29, 2019, 2:53pm UTC](https://discuss.elastic.co/t/dynamic-mapping-confusing-type-inference-behaviour/197371/1 "2019-08-29T14:53:58Z")

</div>

Hi,

I'm using Elasticsearch 6.8.2.

I've been playing with mappings and I've stumbled across this behavior for which I can't find an explanation:

```auto
# Step 0: Creating an index with dynamic mappings enabled
PUT /test-datatypes
{
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "_doc": {
          "properties" : {
              "shortfield" : { "type" : "short" }
          }
      }
    }
}

# Step 1: Add a valid short int
POST /test-datatypes/_doc/1
{
  "shortfield": 1
}

# Step 2: Add a float with many decimals
POST /test-datatypes/_doc/2
{
  "shortfield": 1.1234532145432145765432145867543211234256
}

# Step 3: Add the same float as a JSON string
POST /test-datatypes/_doc/3
{
  "shortfield": "1.1234532145432145765432145867543211234256"
}

# Step 4: Try to add a float with a big integer part 
POST /test-datatypes/_doc/4
{
  "shortfield": 112312.1234532145432145765432145867543211234256
}

# => As expected throws
{
  "error": {
    "root_cause": [
      {
        "type": "mapper_parsing_exception",
        "reason": "failed to parse field [shortfield] of type [short] in document with id '4'"
      }
    ],
    "type": "mapper_parsing_exception",
    "reason": "failed to parse field [shortfield] of type [short] in document with id '4'",
    "caused_by": {
      "type": "json_parse_exception",
      "reason": "Numeric value (112312.1234532145432145765432145867543211234256) out of range of Java short\n at [Source: org.elasticsearch.common.bytes.BytesReference$MarkSupportingStreamInputWrapper@2a672a72; line: 2, column: 64]"
    }
  },
  "status": 400
}

```

If I search the index I get this:

```auto
GET test-datatypes/_search

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 3,
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "test-datatypes",
        "_type" : "_doc",
        "_id" : "1",
        "_score" : 1.0,
        "_source" : {
          # As expected
          "shortfield" : 1
        }
      },
      {
        "_index" : "test-datatypes",
        "_type" : "_doc",
        "_id" : "2",
        "_score" : 1.0,
        "_source" : {
          # Expexted: I would have expected this to throw an error at index time
          # My guess: decimals are truncated to fit in the number of bits of a short
          "shortfield" : 1.1234532145432146
        }
      },
      {
        "_index" : "test-datatypes",
        "_type" : "_doc",
        "_id" : "3",
        "_score" : 1.0,
        "_source" : {
          # Expected: I would have expected this to throw an error at index time
          # Suprising: Not truncated, "raw field"
          "shortfield" : "1.1234532145432145765432145867543211234256"
        }
      }
    ]
  }
}

```

If I look at the mappings I get:

```auto
GET test-datatypes/_search

{
  "test-datatypes" : {
    "mappings" : {
      "_doc" : {
        "properties" : {
          "shortfield" : {
            "type" : "long"
          }
        }
      }
    }
  }
}

```

The things I don't understand are:

1. Why are docs `2` and `3` allowed to be indexed while their types do not match the `short` numerical type.
2. Why doc `2`'s `shortfield` is returned truncated and not doc `3`'s.

I've been trying to find answers in the documentation without success.

Could someone please enlighten me as to why Elasticsearch behaves this way ?  
Thank you

---

<div class="post-metadata">

### Author: ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)
#### Post date: [August 30, 2019, 8:58am UTC](https://discuss.elastic.co/t/dynamic-mapping-confusing-type-inference-behaviour/197371/2 "2019-08-30T08:58:24Z")

</div>

Take a look at the [coercing feature](https://www.elastic.co/guide/en/elasticsearch/reference/7.3/coerce.html), which truncates fields to integers. See also [https://www.elastic.co/guide/en/elasticsearch/reference/7.3/number.html](https://www.elastic.co/guide/en/elasticsearch/reference/7.3/number.html) for the default setting of `coerce`

As you can see in the mapping, by default a long is picked, and the floating point numbers get coerced into a long.

hope this helps.

---

<div class="post-metadata">

### Author: ![timost](https://avatars.discourse-cdn.com/v4/letter/t/e95f7d/32.png) [@timost](https://discuss.elastic.co/u/timost)
#### Post date: [September 13, 2019, 11:17am UTC](https://discuss.elastic.co/t/dynamic-mapping-confusing-type-inference-behaviour/197371/3 "2019-09-13T11:17:32Z")

</div>

Thank you for your answer. I missed the coerce setting !

---

<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: [October 11, 2019, 11:17am UTC](https://discuss.elastic.co/t/dynamic-mapping-confusing-type-inference-behaviour/197371/4 "2019-10-11T11:17:40Z")

</div>

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