5 ms·
From looking at it, the problem is that JSON fails to define "what is a string?" and "what is a number?". Possibly there are duplicate-key concerns as well. Po
by o11c 3y ago
From looking at it, the problem is that JSON fails to define "what is a string?" and "what is a number?". Possibly there are duplicate-key concerns as well.
Postgres's JSONB inherits the definition of Postgres's string and numeric types.
SQLite's JSONB punts the problem down the line to whoever uses the JSON.
(this all is a reminder that JSON is a horrible format and you should never use it if you care about your data)
- Aqueous 3y agoJSON is one of the most succinct formats that you can use to express an arbitrary data shape of hashes, arrays, and primitives. It is highly useful and covers 99% of cases.
- o11c 3y agoand 1% of the time, it just does the wrong thing. It just silent clobber your data; it might crash your program due to creating an incoherent logic state. Who knows?
- theamk 3y agoThe rule is pretty simple: if you have fields which may potentially contain integers with outside of +-2*48 range, or floating points where you care about NaNs -- then do the safe thing and store them as strings. That one simple rule ensures your data won't be clobbered and you program won't crash. (And yes, your serialization/deserialization code will need to contain explicit string conversions. But even with that extra conversion, Javascript is way more interoperable with anything and future-proof than any alternative like protobuf or msgpack)
- swatcoder 3y ago> you should never use it if you care about your data Eh, warts abound all over technology and ubiquity is worth a lot. But because data is important, everybody who does use JSON should make sure they serialize their data in a way the format won’t break. I’ve heard it can be done.
- mardifoufs 3y agoWhat's the alternative to json?
- maxbond 3y agoThere's tons of alternatives. BSON, CBOR, and protobuf are three arbitrary ones.
- miohtama 3y agoXML (:
- mardifoufs 3y agoOn the database?
- maxbond 3y agoThere's actually quite a lot of XML/XSLT support in various proprietary databases (eg RDF databases), and there's Postgres support too: https://www.postgresql.org/docs/current/functions-xml.html https://www.postgresql.org/docs/current/functions-xml.html Iirc XML support in Postgres predates JSON support.
- mardifoufs 3y agoWoah! Ok I didn't know that. How's the performance?
- miohtama 3y agoVery XML'ish
- rubyfan 3y agoMessagePack - https://msgpack.org https://msgpack.org
- 3y ago
- bakugo 3y ago> this all is a reminder that JSON is a horrible format and you should never use it if you care about your data Works on my machine.
- stkdump 3y ago> JSON fails to define "what is a string?" and "what is a number?" Can you elaborate on this? It seems pretty clear from the spec to me: stuff starting with " is a string, stuff starting with - or a digit is a number.
- paulddraper 3y ago"What is a number?" Min value? Max value? Precision (and in what base)?
- stkdump 3y agoSimple, the RFC even calls that out: assume 64 bit float as specified by IEEE and as basically supported everywhere. Why should JSON do anything else than the rest of the world does?
- otabdeveloper4 3y ago64 bit IEEE 754 floating point, as per the spec. Anything else is non-standard.
- paulddraper 3y agoDatadog APIs use 64 bit ints. PostgreSQL also doesn't follow your "standard".
- otabdeveloper4 3y agoThe "standard" is called JSON, and it's not mine, it's made by the IETF. Don't know what a "Datadog" is, and I don't care about Postgres idiosyncrasies.
- Dylan16807 3y agoOkay, let's quote the RFC then. > A number is represented in base 10 using decimal digits. It contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. > This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. That sure doesn't sound like numbers are 64 bit floats, according to the spec.