On Mon, Feb 13, 2012 at 12:32 PM, Benoit Chesneau <[email protected]> wrote: > On Mon, Feb 13, 2012 at 6:26 PM, Paul Davis <[email protected]> > wrote: >> On Mon, Feb 13, 2012 at 3:09 AM, <[email protected]> wrote: >>> I've been following this thread with interest and concern. >>> >>> None of you will know me, so let me first say I'm a Couch end user and >>> developer - and a huge fan of the technology who is worried about the >>> future direction of Couch following the Couchbase debacle. >>> >>> Regardless of the subtleties, what the RFC might say, what other systems >>> might do, to me it seems a screaming fundamental that what I put in to the >>> data store is what comes back from it. >>> >>> If I store 1.0 in a field, I expect to get 1.0 back over the wire. Not 1, >>> 1.0000000000000000000000001 or anything other than exactly the same >>> document that I stored in the first place. >>> >>> Same goes for storing 1 >>> >>> I expect to get back 1, not 1.0 or any other mangled version regardless of >>> how arguably mathematically equivalent it might be. >>> >>> 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. >>> >>> Apologies if I'm missing the point - and obviously I'm new around here, but >>> the one inviolable point to me seems to be that whatever I store, I should >>> get back unchanged. Period. If we break that, we're no longer a data store. >>> >>> Roger >> >> Roger, >> >> Welcome! >> >> The issue here is how we define "same". Given your examples you appear >> to be arguing for byte level equivalence between input and output. >> While this may seem quite logical and even perhaps a necessity for >> something that calls itself a datastore, its not how the world works. >> Rather than convince you, I'll just show two examples: >> >> psql (9.0.5, server 9.0.3) >> Type "help" for help. >> >> davisp=# create table foo(bar REAL); >> CREATE TABLE >> davisp=# insert into foo(bar) values(1.00000000000000000001); >> INSERT 0 1 >> davisp=# select * from foo; >> bar >> ----- >> 1 >> (1 row) >> >> SQLite version 3.7.7 2011-06-25 16:35:41 >> Enter ".help" for instructions >> Enter SQL statements terminated with a ";" >> sqlite> create table foo(bar REAL); >> sqlite> insert into foo(bar) values(1.00000000000000000001); >> sqlite> select * from foo; >> 1.0 >> >> I'd try MySQL but I bet it returns 2.89 because of some bug. >> >> Anyway, my the point is that datastores do change the representation >> of data inserted into them and will have differences in the output >> returned. >> >> So while some may consider this a screaming fundamental, its really a >> whole lot more complicated. >> >> In the end, as we've constantly repeated, anyone that wants the >> absolute best numerical fidelity when using JSON should always use >> strings and rely on application logic to ensure that a suitable >> bignum/bigdecimal implementation exists. >> >> HTH, >> Paul Davis > > I mostly agree, though: > > sqlite> insert into foo(bar) values(1.0); > sqlite> select * from foo; > 1.0 >
Oh, in case I wasn't clear, we should patch ejson so it returns "1.0" for doubles, not arguing there. I'm just railing against the idea that we should attempt some hack at storing tagged user data in a weird attempt to return byte identical representations of data. > > Which isn't the case in couchdb and is somehow problematic and > actually must be solved in 1.2. > > Also I would argue that we are here to provide an alternative to this > real but old world. If we can do better, why not? Also I'm interrested > to know why we are currently limited. If we really can't find a > solution that's ok, however if we do it, and time is the only > constraint maybe it worth a ticket and add on the next release todo ? > > - benoît
