From user-return-7422-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sun Nov 08 03:43:35 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 38278 invoked from network); 8 Nov 2009 03:43:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Nov 2009 03:43:35 -0000 Received: (qmail 63168 invoked by uid 500); 8 Nov 2009 03:43:33 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 63021 invoked by uid 500); 8 Nov 2009 03:43:33 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 63010 invoked by uid 99); 8 Nov 2009 03:43:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Nov 2009 03:43:33 +0000 X-ASF-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.211.186 as permitted sender) Received: from [209.85.211.186] (HELO mail-yw0-f186.google.com) (209.85.211.186) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 08 Nov 2009 03:43:28 +0000 Received: by ywh16 with SMTP id 16so2064382ywh.13 for ; Sat, 07 Nov 2009 19:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=o8FtQeYTqd+IwHOcfAOpoEAFt3VpttMytJKBYqgWYlI=; b=LxRi5Cxwta0zWFkR8E2Z4/RVBKXMMeYpa6EP2z5dEtjDGgIGfWHBIR/fZJ5QXp+SiA WuWLVk+a3kgYa6B42X18scQKE6ghp1tR08LKXCQbA10Xeab+lnnXgvUbkoS7YKmbmLun RAyYm5dnpTIHo7nH6GVpUY9JJ56ODaQjsT/uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=i8f5NJpkDG4qqxsmhIZT8M4Cq7a/Gpr72qAeISriMZB5focZTTBG2cZmdiudUZZ+6S xzfO+BDC0958rYseMYs5xBFACU3YWyj0VRCNoAbyoYoV+ktw+K7GQbs0S04+kaLPFt7n KApJLZH41B3SOdgpQhgVldVKMVdVwlHOTQIq8= MIME-Version: 1.0 Received: by 10.101.136.1 with SMTP id o1mr5683511ann.138.1257651787087; Sat, 07 Nov 2009 19:43:07 -0800 (PST) In-Reply-To: <4AF622D5.9070708@rogerbinns.com> References: <4AF5FB9E.70300@rogerbinns.com> <4AF622D5.9070708@rogerbinns.com> From: Paul Davis Date: Sat, 7 Nov 2009 22:42:47 -0500 Message-ID: Subject: Re: Silent corruption of large numbers To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I don't know what the right solution to this is. =A0I certainly believe t= hat > the view code should error rather than just throw digits away. =A0Or perh= aps > numbers larger than about 60 bits of precision should not be accepted? RFC 4627 does mention this issue in passing in section 4 by saying "An implementation may set limits on the range of numbers." Generally I take this to mean that you're gonna have weird implementation dependent behavior when dealing with the limits of common number representations. As such, relying on the view engine to error out when something else doesn't is gonna be a bit awkward at best. While not the best answer the only thing I can suggest would be to do as Adam says and store large values as strings and use a Bignum library in the places you need to manipulate such values. Even if we told the view server to error on such values, what would that error look like? Would everyone be unable to pass a doc with a big num through the view server (depending on language)? Things get messy quick. HTH, Paul Davis