couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Mon, 13 Feb 2012 10:55:34 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message