couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Mon, 13 Feb 2012 18:32:57 GMT
On Mon, Feb 13, 2012 at 6:26 PM, Paul Davis <> wrote:
> On Mon, Feb 13, 2012 at 3:09 AM,  <> 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);
> 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;

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

View raw message