[ https://issues.apache.org/jira/browse/COUCHDB-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860547#action_12860547 ]
Jarrod Roberson commented on COUCHDB-749: ----------------------------------------- no, in test case 2 with curl the number 9223372036854775807 gets persisted as an integer, just not the correct integer it is 9223372036854776000 no decimal places. I think this is a SERIOUS flaw regardless to WHY it is a flaw. Imagine if Oracle or SQL Server had a flaw that didn't store data correctly. It would be be trusted by many people. I think whatever solution you pick it has to be consistent and preserve the data that is sent in correctly. If that means all numbers get stored as strings and that is the only way to make sure the data is correct then make them all strings. > CouchDB does not persist large values of Numbers correctly. > ----------------------------------------------------------- > > Key: COUCHDB-749 > URL: https://issues.apache.org/jira/browse/COUCHDB-749 > 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 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.