couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarrod Roberson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-749) CouchDB does not persist large values of Numbers correctly.
Date Sat, 24 Apr 2010 17:01:50 GMT

    [ 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.


Mime
View raw message