mort96 on The perils of UUID primary keys in SQLite

Comment on The perils of UUID primary keys in SQLite 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.

sheept 3mo

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)

mort96 3mo

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

sheept 3mo

No you don't? The example I gave produces

    {"a":9007199254740993}

not

    {"a":"9007199254740993"}

mort96 3mo

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`.

sheept 3mo

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)

mort96 3mo

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

marcosdumay 3mo

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.

nh2 3mo

JSON has arbitrary length numbers in the spec only.

mort96 3mo

Completely and utterly irrelevant.

Comments