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