Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4AF622D5.9070708@rogerbinns.com>
Date: Sat, 07 Nov 2009 17:45:57 -0800
From: Roger Binns <rogerb@rogerbinns.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Silent corruption of large numbers
References: <4AF5FB9E.70300@rogerbinns.com>
 <e282921e0911071523n5633d6b8r6d1dbf5a2b43f684@mail.gmail.com>
In-Reply-To: <e282921e0911071523n5633d6b8r6d1dbf5a2b43f684@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Anderson wrote:
> Can you confirm for me that when you load the doc directly (not via a
> view) the number is unchanged? I've tested CouchDB with much larger #s
> (but not in a while).
> 
> If the doc round-trips properly that means the precision is being lost
> inside the spidermonkey view engine, not in our Erlang JSON handling.

As Adam pointed out, the problem is indeed Javascript.  Accessing the
document directly does give the right answer.

Even more amusing is trying to enter or view 9223372036854775807 using
Futon.  If you enter it in the fields tab then the last 4 digits become
6000.  The same thing happens in the source tab which means the source is
being evaluated and redisplayed (annoying).  Displaying the record results
in the 6000 number even if the underlying record is the long number above.

So this means your testing only involved direct REST operations and not
using Futon or views :-)

I don't know what the right solution to this is.  I certainly believe that
the view code should error rather than just throw digits away.  Or perhaps
numbers larger than about 60 bits of precision should not be accepted?

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkr2ItEACgkQmOOfHg372QRfOQCgi4rqYTZh/VszD/2E6xWloBBq
a78AoKb+VEyImwz2eQpF0Xf4Z0qY7NlG
=mUSG
-----END PGP SIGNATURE-----