Antonio-Maranhao commented on issue #1425: URL: https://github.com/apache/couchdb-fauxton/issues/1425#issuecomment-1887599525
Not sure this is something that can be addressed but l will drop some notes from my research on this topic. First of all, there's no 64-bit signed integer in JSON. The [JSON RFC](https://www.rfc-editor.org/rfc/rfc7159#section-6) doesn't specify a limit on the number precision but it sort of implies implementations should use 64-bit float for interoperability. That would make the range of a valid integer to be from `-(2^53)+1` to `(2^53)-1]`. ``` 9_223_372_036_854_775_807 (max signed int64) 9_007_199_254_740_991 (2**53-1) ``` `2**53-1` also matches `Number.MAX_SAFE_INTEGER` from Javascript so one can argue that Fauxton supports the "safe" range for JSON numbers as per the RFC. I can't speak for the CouchDB implementation but it doesn't seem to impose a limit on number values as I was able to add the ridiculously long value below. That means it's treating the JSON as a sequence of characters which is exactly what it is, without converting to any specific machine representation for numbers. ``` {"_id":"doc9","_rev":"1-25ce58eaae037addc94b1fcb06385f5e","n":92233720368547769995425325439238473892174983721894738921478392714893721892} ``` But there's a catch, if you try to use a map/reduce view, you're faced with the same loss of precision since it goes through the JS engine. For instance, using the the view below ``` function (doc) { if (doc.n) { emit(doc._id, doc.n); } } ``` I get these values: ``` {"total_rows":5,"offset":0,"rows":[ {"id":"doc2","key":"doc2","value":2132143}, {"id":"doc6","key":"doc6","value":9223372036854776000}, {"id":"doc7","key":"doc7","value":9223372036854778000}, {"id":"doc8","key":"doc8","value":9007199254740991}, {"id":"doc9","key":"doc9","value":9.223372036854777e+73} ]} where {"_id":"doc6","_rev":"1-6292f628aa9e691f51018f0cf1953e37","n":9223372036854776807} {"_id":"doc9","_rev":"1-25ce58eaae037addc94b1fcb06385f5e","n":92233720368547769995425325439238473892174983721894738921478392714893721892} ``` So my take is that there's an implicit limit to what numbers you can store in CouchDB so you don't run into loss of precision, and that limit matches what Fauxton supports. --- All that said, the potential for data loss is still there. In theory, Fauxton could be updated to treat JSON as string only and never parse the value as a object, but the same would have to be true for any JS dependencies in use. All in all, it's a hard ask, and I'll leave it at that for now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@couchdb.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
