I just saw very strange behavior in couchbase database. When storing document with this number ‘10100910170682465’ it saved it as ‘10100910170682464’ (1 less).
The funny thing is that it works only with certain combinations e.g. 10100910170682470 is stored correctly.
To reproduce this issue, just create sample document in any bucket and set any field value to 10100910170682460 (but number not string):
This is a common limitation of JSON parsers, and results from the origins in Javascript where numbers are represented as a 64-bit floating-point value (aka double). As you’ve discovered the standard solution to this is to store anything not exactly representable in a 64-bit float (i.e. anything with more than 53bits of precision) as a String.
To give some more detail on what is happening - during parsing / conversion of the number to a JSON document, it is converted to a double, which doesn’t have the precision to represent the least-significant digits of your number. Hence when the document is stored in Couchbase (and subsequently read), you’ll see the truncated value.
You don’t say how you’re storing the document, but this is probably common to a number of SDKs / JSON libraries, possibly including the Couchbase GUI (as that is written partially in Javscript and so will suffer from the same limitation).
You’ll find lots of information on this kind of issue on the 'net (for example 2, 3, 4).
I should be clear about the server’s behaviour here: Couchbase stores the raw bytes of whatever you specify - the “corruption” if you will is occurring while preparing the bytes to store to the Bucket.
