BigInt field precision loss

[unendingblue]

Describe the bug
When querying features that have fields with BigInt values, the JSON response returns them in their numerical form instead of a stringified version.

Even though I wish this was not the case, the JSON specification unfortunately does not cover BigInts, resulting in precision loss (usually the last 2-3 digits) when parsing Tile38's responses.

To Reproduce

SET USER 1 FIELD bigintfield 385189776128479232 POINT 0 0
GET USER 1 WITHFIELDS

Tile38 response (string)

{"ok":true,"object":{"type":"Point","coordinates":[0,0]},"fields":{"bigintfield":385189776128479232}}

JSON parsed (JS object)

{"ok":true,"object":{"type":"Point","coordinates":[0,0]},"fields":{"bigintfield":385189776128479200}}

This behavior is consistent across all GET output formats (OBJECT/POINT/BOUNDS)

Expected behavior
Tile38 should stringify BigInt fields when the OUTPUT mode is set to JSON.

[unendingblue]

some further observations - when SETing a key with a bigintfield field via a Redis-compatible JS client, it is possible to stringify the value by encapsulating it with double quotes. trying the same command via the CLI does not yield the same result. eg:

SET USER 1 FIELD bigintfield "385189776128479232" POINT 0 0

still inserts the data as a number

@tidwall would love your insight on this

[tidwall]

Tile38 tries to be unopinionated about field formats. It defaults to a number format, but can support strings too.

Unfortunately very big numbers (above 53-bit integers) are often truncated by most JSON libraries which treat all numbers as 64-bit floats.

As you discovered, wrapping the number in quotes ensures the number is preserved as a string.
For the CLI, you'll need to outer-wrap with single quotes.

SET USER 1 FIELD bigintfield '"385189776128479232"' POINT 0 0

[unendingblue]

thank you for the info!