# Painless Elasticsearch update do not handle big numbers

**URL:** <https://discuss.elastic.co/t/painless-elasticsearch-update-do-not-handle-big-numbers/342633>\
**Category:** Elasticsearch\
**Tags:** painless\
**Created:** [September 8, 2023, 4:50pm UTC](https://discuss.elastic.co/t/painless-elasticsearch-update-do-not-handle-big-numbers/342633 "2023-09-08T16:50:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![DidierB](https://avatars.discourse-cdn.com/v4/letter/d/ed8c4c/32.png) [@DidierB](https://discuss.elastic.co/u/DidierB)\
**Post date:** [September 8, 2023, 4:50pm UTC](https://discuss.elastic.co/t/painless-elasticsearch-update-do-not-handle-big-numbers/342633/1 "2023-09-08T16:50:53Z")

</div>

Hello,

I'm using an index that contains big numbers (tracking data byte count per IP). Each time I see an IP in the log I extract the size of the request and add it to an index with the IP as a key. The index has a mapping that say that this "size" number is a long and should go to 2^63. The problem is that I do updates with a painless procedure and it doesn't work. It looks like the painless script only uses integer (2^32).

How to reproduce:

Store the update script, create the template to play with LONG numbers and destroy any existing index so it is recreated with the template next time.

```auto
POST /_scripts/eci_test1_script
{
  "script": {
    "lang": "painless",
    "source": "ctx._source.bignumber += params['bignumberincrement']"
  }
}

PUT /_index_template/eci_test1_template
{
  "index_patterns": [
    "eci_test1"
  ],
  "template" : {
    "mappings": {
      "_doc": {
        "properties" : {
            "bignumber": {
              "type": "long"
            }
          }
        }
      }
    }
  }
}

DELETE /eci_test1

```

Now post the upsert and check for the value. Do it **three times**.

```auto
POST eci_test1/_update/mydoc1
{
  "script" : {
    "id" : "eci_test1_script",
    "params" : {
      "bignumberincrement" : 1000000000
    }
  },
  "upsert" : {
    "bignumber" : 1000000000
  }
}

GET /eci_test1/_doc/mydoc1

```

What I have:

```auto
{
  "_index" : "eci_test1",
  "_type" : "_doc",
  "_id" : "mydoc1",
  "_version" : 3,
  "_seq_no" : 2,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "bignumber" : -1294967296
  }
}

```

_bignumber_ should be 3000000000.

---

<div class="post-metadata">

**Author:** ![DidierB](https://avatars.discourse-cdn.com/v4/letter/d/ed8c4c/32.png) [@DidierB](https://discuss.elastic.co/u/DidierB)\
**Post date:** [September 11, 2023, 11:30am UTC](https://discuss.elastic.co/t/painless-elasticsearch-update-do-not-handle-big-numbers/342633/2 "2023-09-11T11:30:54Z")

</div>

Found a workaround. **Do not use the increment operations.**

Instead of

```auto
# BUGGY with LONG
ctx._source.bignumber += (long) params['bignumberincrement']

```

Use

```auto
# WORKS
ctx._source.bignumber = (long) ctx._source.bignumber + (long) ctx._source.bignumber params['bignumberincrement']

```

---

<div class="post-metadata">

**Author:** ![stu](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stu/32/75063_2.png) [@stu](https://discuss.elastic.co/u/stu)\
**Post date:** [September 12, 2023, 4:10pm UTC](https://discuss.elastic.co/t/painless-elasticsearch-update-do-not-handle-big-numbers/342633/3 "2023-09-12T16:10:37Z")

</div>

Hi @DidierB. What's happening is the `_source` is being parsed from json without knowledge of the mappings, so it is defaulting to `int`.

You're right, the work around is to force `ctx._source.bignumber` to be a `long` on every update by assigning it.

---

<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 10, 2023, 4:11pm UTC](https://discuss.elastic.co/t/painless-elasticsearch-update-do-not-handle-big-numbers/342633/4 "2023-10-10T16:11:24Z")

</div>

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