couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Mon, 13 Feb 2012 17:26:23 GMT
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



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);
davisp=# select * from foo;
(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;

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

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.

Paul Davis

View raw message