1

I am using a Couchbase view to emit a few records. Among those records, there is one record which is 19 digit long. When Couchbase view (written in javascript) pulls those record, it rounds off the record into smaller one and loses precision.

-7092643922943239825 is actual number but when retrieved from below view:

function(doc, meta) {
if (doc.docType == 'xyz') {
    if (doc.source) {
            if (doc.source != null) {
                emit([doc.valA, doc.valB,  loc], 1);
            }
    } 
}

The output I get is:

[ **-7092643922943240000, 1523365218128317200**, "abc" ]

I was expecting:

"doc": {
  "valA": 1523365218128317302,
  "valB": -7092643922943239825
}

What am I doing wrong?

Matthew Groves
  • 25,181
  • 9
  • 71
  • 121
deewreck
  • 113
  • 7
  • 2
    well ... `1523365218128317302 > Number.MAX_SAFE_INTEGER` and `-7092643922943239825 < Number.MIN_SAFE_INTEGER` so, they can't safely be represented as Numbers without loss of precision - have you tried `-7092643922943240000n` and `1523365218128317200n`? – Jaromanda X Sep 02 '22 at 08:12
  • adding "n" with actual number, allows to get required output. but since i am pulling this data from DB, i can't actually change original number to have "n" suffix. – deewreck Sep 02 '22 at 08:23
  • Oh, so the server is sending those values as numbers not strings ... you can't fix the server? – Jaromanda X Sep 02 '22 at 08:25
  • 2
    it won't be straight forward. since these documents are already present in DB now. we won't be able to change datatype of existing documents , without re-running entire process. – deewreck Sep 02 '22 at 08:30
  • so, the DB stores those values as a numeric value - is it a 64bit integer? – Jaromanda X Sep 02 '22 at 08:32
  • its a long datatype in the model – deewreck Sep 02 '22 at 08:40
  • not familiar with couchbase enough to help, sorry – Jaromanda X Sep 02 '22 at 08:41
  • Have you tried to immediately use BigInt(number_from_server) when getting it? It's similar to ...n, but in order to append an "n" you'd first have to parse the number, where the loss already happens. Using the proper conversation method above might circumvent the step where the precision-loss happens? – Foxcode Sep 02 '22 at 09:16
  • yes, i tried using BigInt as well but got same result. i used emit([bigInt(doc.valA), doc.valB, loc], 1); I have also used parseInt(). valueOf() and toString() but nothing does the work. it seems like value already comes changed , when view is executed. – deewreck Sep 02 '22 at 09:23
  • Related discussion on Couchbase Forum: https://forums.couchbase.com/t/couchbase-view-rounds-off-the-long-value-in-emit/34370 – dnault Sep 02 '22 at 22:06

1 Answers1

0

It seems like you have cross posted this question, please refer to a detailed discussion concerning your issue as posted to https://forums.couchbase.com/t/couchbase-view-rounds-off-the-long-value-in-emit/34370 (the link was previously referenced by dnault)

Jon Strabala
  • 421
  • 3
  • 3