# number value change when insert 11258999069452421

Elastic Search
1

Elastic Search

I create a new index with

PUT /cq_sample_index
{
  "mappings": {
    "properties": {
      "code": {
        "type": "long"
      },
      "code2": {
        "type": "keyword"
      },
      "code3": {
        "type": "keyword"
      },
      "category": {
        "type": "keyword"
      },
      "description": {
        "type": "text"
      }
    }
  }
}

I insert a doc with

POST /cq_sample_index/_doc/2
{
  "code": 11258999069452421,
  "code2": 11258999069452421,
  "code3": "11258999069452421",
  "category": "books",
  "description": "A book about advanced Elasticsearch usage and optimization."
}

I got this

      {
        "_index": "cq_sample_index",
        "_id": "2",
        "_score": 1,
        "_source": {
          "code": 11258999069452420,
          "code2": 11258999069452420,
          "code3": "11258999069452421",
          "category": "books",
          "description": "A book about advanced Elasticsearch usage and optimization."
        }
      }

As you can see , the value of code and code2 changed

So why ?

I've tried es8.11.1\ es8.11.4 \ es8.12.1
and I insert data with kibana and python code ， same result

2

It seems a kibana bug ， I got the correct result with python code; I use kibana 8.11.4 , I supposed to be sovled.

3

I can reproduce with curl :

curl -s -k -u "${EUSER}":"${EPASS}" -X POST -H "Content-Type: application/json" -d \
'{"code0":11258999069452420,"code1":11258999069452421,
  "code2":11258999069452422,"code3":11258999069452423,
  "code4":11258999069452424,"code5":11258999069452425,
  "code6":11258999069452426,"code7":11258999069452427,
  "code8":11258999069452428,"code9":11258999069452429,
"category":"books",
"description":"A book about advanced Elasticsearch usage and optimization."}' \
"https://localhost:9200/cq_sample_index2/_doc/2"

the doc is indexed as

    "hits": [
      {
        "_index": "cq_sample_index2",
        "_id": "2",
        "_score": 1,
        "_source": {
          "code0": 11258999069452420,
          "code1": 11258999069452420,
          "code2": 11258999069452422,
          "code3": 11258999069452424,
          "code4": 11258999069452424,
          "code5": 11258999069452424,
          "code6": 11258999069452426,
          "code7": 11258999069452428,
          "code8": 11258999069452428,
          "code9": 11258999069452428,
          "category": "books",
          "description": "A book about advanced Elasticsearch usage and optimization."
        }
      }
4

I believe this will depend on the JSON library used as the length of the number exceeds standard JSON precision. If you want to index long numbers, map them as long and send the numbers the way you did for the code3 field.

5

Right, it's to do with the difficulty of representing integers when they are cosnidered as floating point numbers, specifically IEEE-754. A 64-bit floating point number has only around 15/16 digits of precision. So the 18-digit integers here, though well within the range of the long datatype, are problematic.

It is not at all obvious when or if tool X might be doing any intermediate conversions internally. e.g. when I do my POST view curl I see following:

=> Send header, 217 bytes (0xd9)
0000: POST /cq_sample_index2/_doc/2 HTTP/1.1
0028: Host: localhost:9200
007d: User-Agent: curl/8.7.1
0095: Accept: */*
00a2: Content-Type: application/json
00c2: Content-Length: 360
00d7:
=> Send data, 360 bytes (0x168)
0000: {"code0":1258999069452420,"code1":1258999069452421,.  "code2":12
0040: 58999069452422,"code3":1258999069452423,.  "code4":1258999069452
0080: 424,"code5":1258999069452425,.  "code6":1258999069452426,"code7"
00c0: :1258999069452427,.  "code8":1258999069452428,"code9":1258999069
0100: 452429,."category":"books",."description":"A book about advanced
0140:  Elasticsearch usage and optimization."}
== Info: upload completely sent off: 360 bytes

so its not curl doing any conversion, must be within elasticsearch's own supporting libraries.

@chenqi - The solution is as @Christian_Dahlqvist wrote - be explicit on the mapping AND quote the integers.