On Feb 13, 2012 1:10 AM, <roger.moffatt <[email protected]>@<[email protected]> gmail.com <[email protected]>> 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.
