couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Kocoloski (JIRA)" <>
Subject [jira] Commented: (COUCHDB-749) CouchDB does not persist large values of Numbers correctly.
Date Fri, 23 Apr 2010 18:02:49 GMT


Adam Kocoloski commented on COUCHDB-749:

Hi Jared, in case 2) the number is actually persisted as 9223372036854776000.0, right?

The current behaviour of CouchDB's JSON decoder (mochijson2) is that numbers larger than the
32 bit integer limit are decoded as floating-point.  That's why you observe the rounding error
in Case 2.  It's an arbitrary restriction; we could certainly store them unaltered using Erlang's
BigNums.  On the other hand, any time you tried to access the number in a javascript view
you'd lose information, due to the fact that ECMAScript uses double precision floating-point
for _all_ numbers.

The Futon issue in 1) is also due a limitation of javascript iirc.

I'm not sure what the right solution is here:

a) reject bignums
b) store them as floating-point
c) store them unaltered, but the view engine will still silently change them
d) store them as strings

As an app developer I would choose d).  We used to do c) in CouchDB, but at one point we reverted
to the default behavior of mochijson2.

Given that the view engine cannot correctly work with numbers that have more than 15 digits
of precision, what would you have us do?

> CouchDB does not persist large values of Numbers correctly.
> -----------------------------------------------------------
>                 Key: COUCHDB-749
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>    Affects Versions: 0.11
>         Environment: All
>            Reporter: Jarrod Roberson
> All the following operations exhibit the same bug, large numbers don't get persisted
correctly. They get something added to them for some reason.
> 9223372036854775807 == java.lang.Long.MAX_VALUE
> 1: go into Futon, create a new document and create a new field and enter the number 9223372036854775807,
click the green check mark, the number changes to 9223372036854776000 even before you save
> 2.curl -X PUT http://localhost:5984/test/longTest -d '{"value": 9223372036854775807}',
the number gets persisted as 9223372036854776000
> trying to persist System.currentTimeMilliseconds() from java causes the same thing to
happen occasionally.
> This seems to be a pretty serious bug if I can't trust that my data is not being corrupted
when submitted to the database.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message