You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This can fail silently by downcasting a bigint returned from the database into a JS number, causing data loss if the same value is later saved, for example SELECT followed by UPDATE.
In TypeScript, when casting the rows to types, the downcast is not obvious.
Luckily this was caught using integration tests.
The connection can be configured to return strings, but why not use native types? @sidorares
/**
* When dealing with big numbers (BIGINT and DECIMAL columns) in the database, you should enable this option
* (Default: false)
*/
supportBigNumbers?: boolean;
/**
* Enabling both supportBigNumbers and bigNumberStrings forces big numbers (BIGINT and DECIMAL columns) to be
* always returned as JavaScript String objects (Default: false). Enabling supportBigNumbers but leaving
* bigNumberStrings disabled will return big numbers as String objects only when they cannot be accurately
* represented with [JavaScript Number objects](https://262.ecma-international.org/5.1/#sec-8.5)
* (which happens when they exceed the [-2^53, +2^53] range), otherwise they will be returned as Number objects.
* This option is ignored if supportBigNumbers is disabled.
*/
bigNumberStrings?: boolean;
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt
Instead of treating MySQL BIGINT as String, It would be great if we could use JavaScript BigInt primitive.
The text was updated successfully, but these errors were encountered: