Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.210.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAE2x-Ei0e3ge_56ObS_AFMxG3bsCP7gMc4K1OVvG9c8jX4S_Gw@mail.gmail.com>
References: 
 <CA+Y+444JKqhZvfZduqMmqaR1nCZU9Uvts_W9QCjxSfsnFdwmfA@mail.gmail.com>
	<CAN-3CBJDzfqgWc+Ouvdue8Xs+WO1b5ZCQrYBTZHRb3TPRGVkEw@mail.gmail.com>
	<CA+Y+444LOQ6=jYSKcmFZLH55xAOVfUd_m5V0xGuCeoTRLHmLag@mail.gmail.com>
	<CAN-3CBJ+tad3A5cjwKYTV9TkK=k5P35=nkaWfkNmhagZ8Cdnkw@mail.gmail.com>
	<CAAL6JQja5eXOkuqnWr2eT+kKHfufHyC2pFPp2TRiwjLjcJz-gA@mail.gmail.com>
	<CAAL6JQjhNWJTrX6s9xni=11-PP2V-3nmdA+1VDMjieLxarJWNQ@mail.gmail.com>
	<CAN-3CBJ0LGTc3gXGQc9Fa+2LKEqo4Q2fkOYvo1kNdGDSUu9hGQ@mail.gmail.com>
	<CAJNb-9pE6ZdiJ3Za6_uRXRWbH05p88QjUg5wxN6Vuc22nYt=CQ@mail.gmail.com>
	<CABvT1DGqPdKvytCTiNknwhuB7EotTbgHUR+cx2y0VEV0NUt-Cw@mail.gmail.com>
	<CAJ_m3YDhYtzQOw4iYcgu54H86-jvPJYE=J_VaVnDYE_eEFH6DQ@mail.gmail.com>
	<CAN-3CBK=nO5-Rvnj9JO5+Op2zydhEi5Wn6_bmmO2TL8kfHffbg@mail.gmail.com>
	<CAE2x-Ei0e3ge_56ObS_AFMxG3bsCP7gMc4K1OVvG9c8jX4S_Gw@mail.gmail.com>
Date: Mon, 13 Feb 2012 02:55:34 -0800
Message-ID: 
 <CAAL6JQhac3mp-4w2dScnBdrstHdT8JGCXMyYp=idzjiRBerH6A@mail.gmail.com>
Subject: Re: [VOTE] Apache CouchDB 1.2.0 release, first round
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7b33d19e60ad1a04b8d651b2

--047d7b33d19e60ad1a04b8d651b2
Content-Type: text/plain; charset=UTF-8

On Feb 13, 2012 1:10 AM, <roger.moffatt
<roger.moffatt@gmail.com>@<roger.moffatt@gmail.com>
gmail.com <roger.moffatt@gmail.com>> wrote:
>
> So rule 1 has to be, whatever I put in, I get back.
>
> What happens at a view level is different. If I've stored 1.0 or 1 as a
> numeric (ie non-string) value, then what happens in the javascript of a
> view is more flexible. Here I'm living in the real world of nasty floats
> etc and in this case my view code should take appropriate care of what the
> number might actually be. I'd kind of expect anything with a decimal point
> to be interpreted as a float and anything without one to be interpreted as
> an integer. That seems pretty basic and easy to understand.

Thanks, Roger. You seem to be touching on is the fact that CouchDB puts
incoming JSON through a round trip always, and Paul that floats always
incur lossy transformations. Since we can't fix encoding/decoding in
general (though we can for integers), we'd like not to touch the JSON that
hits disk so that it's always stored verbatim, but API responses need to
insert metadata for many requests. I recall that Paul objected to the
string manipulation that would be required to join the disk JSON with the
meta properties.

A very rigorous approach might be to work with the tokenized, but not
decoded, JSON so that numeric field values could be passed verbatim. For
1.2 I'd just like to see the integer regression patched.

--047d7b33d19e60ad1a04b8d651b2--