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 <[email protected]> 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
