undefined

points

by Fabricio2016 hours ago |

[-]

Good trick is to prefix all such keys with magic, i.e. a couple of letters that identify type type of key.

Then it will always be a string and you will be free to change the format/type of the key in the future to UUID or whatever you like.

by zmj3 hours ago|

parent|

[-]

Rule of thumb: if you’re not doing math with a value, it’s not a number.

by myko43 minutes ago|

parent|

[-]

I've been preaching this for years but nobody believes me until it bites them in the ass

by Piezoid9 hours ago|

prev|

[-]

Using a Feistel cipher and base 32 encoding at the boundaries of the system can help catching vibe coded edge code that attempt to decode identifiers in javascript. It also somewhat obfuscate the cardinalities and fill rate of the tables.

by sheept9 hours ago|

prev|

[-]

This can be avoided by supplying a reviver:

    const json = '{ "a": 9007199254740993 }'
    JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)

by tyre1 hours ago|

parent|

[-]

Which can be avoided by using UUIDs

by jraph24 minutes ago|

parent|

[-]

Or by putting that id between quotes so it's a string.

by spiffytech16 hours ago|

prev|

[-]

Fortunately we're seeing more JS DB libraries offering to read large numbers as the BigInt type.

by shakna13 hours ago|

parent|

[-]

But frustratingly, a JS BigInt is nothing like a BigInt in any other language.

In JS - BigInt is 64bit integer.

In anything else - BigInt is a arbitrarily large integer.

by anematode13 hours ago|

parent|

[-]

Hm? JavaScript BigInts are arbitrary precision, and you need to use methods like BigInt.asIntN(64, a) to convert them to 64 bits

by mort9612 hours ago|

parent|

[-]

I hate this so much because you can’t nicely serialise a BigInt as JSON. Using a string is nicer but it only makes sense where int64 is used as an ID, not where it’s used as a number; and you don’t wanna have to configure this per field per query.

by marcosdumay1 hours ago|

parent|

[-]

IMO, I'm tending toward thinking that having types on your readable serialization format is a mistake, and that they should be always input to the (de)serializer instead.

by sheept9 hours ago|

parent|

prev|

[-]

You can serialize a BigInt by specifying a replacer:

    const obj = { a: 9007199254740993n }
    JSON.stringify(obj, (_key, value) => typeof value === 'bigint' ? JSON.rawJSON(value.toString()) : value)

by mort969 hours ago|

parent|

[-]

And then you end up with strings on the other side, not numbers.

by sheept8 hours ago|

parent|

[-]

No you don't? The example I gave produces

    {"a":9007199254740993}

not

    {"a":"9007199254740993"}

by mort965 hours ago|

parent|

[-]

Oh, that's much worse! The JSON string `{"a":9007199254740993}` decodes to the object `{"a":9007199254740992}` with typical JSON parsers like JavaScript's `JSON.parse`.

by sheept1 hours ago|

parent|

[-]

If you're applying a replacer, then you'd supply a reviver when parsing:

    const json = '{ "a": 9007199254740993 }'
    JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)

by mort961 hours ago|

parent|

[-]

Yeah but now you have the world's biggest foot gun in your API.

by nh211 hours ago|

parent|

prev|

[-]

JSON has arbitrary length numbers in the spec only.

by mort969 hours ago|

parent|

[-]

Completely and utterly irrelevant.

by Etheryte12 hours ago|

parent|

prev|

[-]

This is simply not true? Or maybe I misunderstand what you mean?

by paulddraper16 hours ago|

prev|

[-]

Node.js drivers will correctly read int64 as string or bigint, not number.

E.g. pg for PostgreSQL

Maybe there’s a buggy driver but I don’t know it.

by Fabricio201 hours ago|

parent|

[-]

Browser!! The browser reads it as Number. If your rest api returns {"id": 1324535222364012585} for example, javascript will try and parse that as number from the response!!!

You can of course, change the api such that it does {"id": "1324535222364012585"} instead and voila, it will no longer try parsing it as number. Or the many other workarounds people have recommended above (like appending a prefix, or using a different encoding), but why is it trying to parse a number thats too big and instead of throwing it just rounds down without telling you????!