couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Silent corruption of large numbers
Date Sat, 07 Nov 2009 23:50:11 GMT
Yep, this is JavaScript's rather strange idea to represent all Numbers  
as double-precision floating point.  Large integers get corrupted in  
the process -- you only get 15 digits of precision.  My workaround has  
been to save these big integers as strings.

As Chris alluded to, the document itself should be OK, but all  
roundtrips through SpiderMonkey will not represent the value correctly.

We need to put this in the wiki at some point.  Best,

Adam

On Nov 7, 2009, at 6:23 PM, Chris Anderson wrote:

> Roger,
>
> Can you confirm for me that when you load the doc directly (not via a
> view) the number is unchanged? I've tested CouchDB with much larger #s
> (but not in a while).
>
> If the doc round-trips properly that means the precision is being lost
> inside the spidermonkey view engine, not in our Erlang JSON handling.
>
> Thanks,
> Chris
>
> On Sat, Nov 7, 2009 at 2:58 PM, Roger Binns <rogerb@rogerbinns.com>  
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> As part of my testing I create a document containing an integer  
>> that is the
>> largest that can be represented in a signed 64 bit quantity.  On  
>> getting the
>> document back from couchdb it is an even larger number!  I used  
>> Wireshark to
>> make sure this is not some other intermediary component messing up.
>>
>> I used _bulk_docs:
>>
>>  {"docs": [{"_id": "92ba99b6683541bc8d27558f219abfd1", "val":
>> 9223372036854775807}]}
>>
>> Response:
>>
>>   HTTP/1.1 201 Created
>>
>> Reading back again (via a view):
>>
>>  {"total_rows":1,"offset":0,"rows":[
>> {"id":"92ba99b6683541bc8d27558f219abfd1","key":null,"value": 
>> ["1-88f82719afe029f8f16597bb0992f115",9223372036854776000]}
>>
>> ]}
>>
>> What I sent: 9223372036854775807
>> Get back:    9223372036854776000.
>>
>> The number coming back can't be represented in a 64 bit signed  
>> quantity
>> which then trips various things in my test suite.
>>
>> Roger
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkr1+5oACgkQmOOfHg372QT81wCgh3xGe9s8kb1DFlcZyyeXlu0d
>> lnkAoIPYLrBmuR0dH3SuqfIQeR6VzrSY
>> =53D3
>> -----END PGP SIGNATURE-----
>>
>
>
>
> -- 
> Chris Anderson
> http://jchrisa.net
> http://couch.io


Mime
View raw message