couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Mon, 13 Feb 2012 18:43:56 GMT
On Mon, Feb 13, 2012 at 12:32 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Mon, Feb 13, 2012 at 6:26 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> On Mon, Feb 13, 2012 at 3:09 AM,  <roger.moffatt@gmail.com> 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

Mime
View raw message