couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <>
Subject Re: [ANNOUNCE] Apache CouchDB 1.0.0 has been released
Date Thu, 15 Jul 2010 17:43:28 GMT

On Jul 15, 2010, at 10:32 AM, Jarrod Roberson wrote:

> Did this issue ( ) get
> resolved in 1.0?
> Personally it is a real show stopper, there is a work around ( store all
> largish numbers as strings ), but it is serious.

This is fixed in trunk.

If you touch JavaScript at all (browser, view engine, etc) it will round your numbers.

I you don't touch JavaScript, it is solid.

On 1.0:

$ curl -X PUT http://localhost:5984/a/longerTest -d '{"value":9223372036854775807922337203685477580792233720368547758079223372036854775807}'
animal 10:42:29 ~/code/couchdb(trunk) jchris
$ curl http://localhost:5984/a/longerTest

I've also pushed the fix upstream to mochiweb, so that we don't have this regression again.


> If not it needs to be documented if not, it bit me and only my unit tests
> caught it.
> 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 it.
> 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.

View raw message