For some columns in databases, we use BIGINT UNSIGNED datatype. However, the following factors do not allow to use values that do not fit more than 53bits:
- NodeJS number datatype
- JSON number, only range of [-(2 ^ 53)+1, (2 ^ 53)-1] is guaranteed to work in JSON
https://datatracker.ietf.org/doc/html/rfc7159#page-6
Examples:
% node -e 'console.log(JSON.stringify({"foobar": 18446744073709551615}))'
{"foobar":18446744073709552000}
% node -e 'console.log(JSON.parse("{"foobar": 18446744073709551615}"))'
{ foobar: 18446744073709552000 }
This causes issues if we convert autoincrement bigint unsigned to auto_random, as it almost immediately exceeds 53bit value by using the full range.
So limiting, e.g. AUTO_RANDOM(5, 6) instead of AUTO_RANDOM(5) (thus using only 6 bytes) might solve this issue.
This might be useful to allow to migrate back to auto_increment - if we limit the range when migrating to auto_random - so we have enough values free between the current and maximum.
For some columns in databases, we use BIGINT UNSIGNED datatype. However, the following factors do not allow to use values that do not fit more than 53bits:
https://datatracker.ietf.org/doc/html/rfc7159#page-6
Examples:
% node -e 'console.log(JSON.stringify({"foobar": 18446744073709551615}))'
{"foobar":18446744073709552000}
% node -e 'console.log(JSON.parse("{"foobar": 18446744073709551615}"))'
{ foobar: 18446744073709552000 }
This causes issues if we convert autoincrement bigint unsigned to auto_random, as it almost immediately exceeds 53bit value by using the full range.
So limiting, e.g. AUTO_RANDOM(5, 6) instead of AUTO_RANDOM(5) (thus using only 6 bytes) might solve this issue.
This might be useful to allow to migrate back to auto_increment - if we limit the range when migrating to auto_random - so we have enough values free between the current and maximum.