-
|
Seems like long integer values get rounded/truncated. I'm assuming this is due to a Javascript limitation? In a view, a 64 bit timestamp value many times gets truncated, so the key returned is not actually equal to the value. Do I need to configure something to fully support 64 bit values? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
Yes that's right -- any number that takes a roundtrip through JavaScript (e.g. by emitting it in a view) will be converted into a double-precision floating point, which will definitely result in some corruption of integer values greater than I believe you can avoid this if you're able to use the Mango system to define and query your indexes, as Mango bypasses JS altogether. But if that 64 bit integer ever ends up in JS somewhere else in your stack it will get corrupted there, too, so be careful. |
Beta Was this translation helpful? Give feedback.
-
|
Adam, thanks for the quick reply. I'm pretty new to CouchDB. From the limited doc I see about it, is Mango a separate query interface? Does it have its own separate indexes? |
Beta Was this translation helpful? Give feedback.
-
|
Mango is the newer interface to query CouchDB. It allows querying documents with Mango (A query syntax similar to the one used by MongoDB). More details available here: https://docs.couchdb.org/en/stable/api/database/find.html |
Beta Was this translation helpful? Give feedback.
Yes that's right -- any number that takes a roundtrip through JavaScript (e.g. by emitting it in a view) will be converted into a double-precision floating point, which will definitely result in some corruption of integer values greater than
Number.MAX_SAFE_INTEGER.I believe you can avoid this if you're able to use the Mango system to define and query your indexes, as Mango bypasses JS altogether. But if that 64 bit integer ever ends up in JS somewhere else in your stack it will get corrupted there, too, so be careful.