On Jul 15, 2010, at 10:32 AM, Jarrod Roberson wrote: > Did this issue ( https://issues.apache.org/jira/browse/COUCHDB-749 ) 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}' {"ok":true,"id":"longerTest","rev":"1-28f8c7811de99149fcb49912a391ab13"} animal 10:42:29 ~/code/couchdb(trunk) jchris $ curl http://localhost:5984/a/longerTest {"_id":"longerTest","_rev":"1-28f8c7811de99149fcb49912a391ab13","value":9223372036854775807922337203685477580792233720368547758079223372036854775807} I've also pushed the fix upstream to mochiweb, so that we don't have this regression again. Chris > 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.
