couchdb-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/COUCHDB-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860711#action_12860711
] 

Chris Anderson commented on COUCHDB-749:
----------------------------------------

Since we are only concerned with storage and round-trip, it doesn't matter about Erlang arithmetic.

I think we should patch our JSON parser to handle arbitrary ints again.

We should clearly document that the view server doesn't have the same integer guarantees as
the storage engine. I don't agree that we should adopt spidermonkey's limitations. The JSON
spec is very clear on the fact that a valid JSON implementation may support only very small
numbers. (Eg you can round everything to 0 and still be valid JSON.) That's no reason for
us to act that way.

> 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