From dev-return-20621-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Feb 13 18:52:44 2012
Return-Path:
X-Original-To: apmail-couchdb-dev-archive@www.apache.org
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id B08D79EB8
for ; Mon, 13 Feb 2012 18:52:44 +0000 (UTC)
Received: (qmail 49768 invoked by uid 500); 13 Feb 2012 18:52:44 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 49707 invoked by uid 500); 13 Feb 2012 18:52:43 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 49694 invoked by uid 99); 13 Feb 2012 18:52:43 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Feb 2012 18:52:43 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of kevin.r.coombes@gmail.com designates 209.85.160.180 as permitted sender)
Received: from [209.85.160.180] (HELO mail-gy0-f180.google.com) (209.85.160.180)
by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Feb 2012 18:52:35 +0000
Received: by ghbz22 with SMTP id z22so3226006ghb.11
for ; Mon, 13 Feb 2012 10:52:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=message-id:date:from:organization:user-agent:mime-version:to:cc
:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=VkGSWX49gn28d1xPddZo2QoR51JtwA7fU2xHvuFZjKE=;
b=B9r+rItH03og3oO6ouPJDPk2zUgBoAgwPQ7cP/R7R84tR+jrS9k+juSUWseAn1tOtd
BJgG2YAbEvgbJAUU1OX/zLsXEImCdnn9cC5LmFIgoGm6AgPrdrMp91myELxPfvJVzzdP
/LkWv0XbsXf2GOMkOTrYyky81Qga7zJf/2bRA=
Received: by 10.236.117.231 with SMTP id j67mr21667971yhh.59.1329159134909;
Mon, 13 Feb 2012 10:52:14 -0800 (PST)
Received: from [10.105.35.136] ([143.111.22.28])
by mx.google.com with ESMTPS id i2sm25565516yhf.16.2012.02.13.10.52.13
(version=TLSv1/SSLv3 cipher=OTHER);
Mon, 13 Feb 2012 10:52:14 -0800 (PST)
Message-ID: <4F395BDC.9020604@gmail.com>
Date: Mon, 13 Feb 2012 12:52:12 -0600
From: "Kevin R. Coombes"
Organization: UT M.D. Anderson Cancer Center
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: dev@couchdb.apache.org
CC: "Paul Joseph Davis (Commented) (JIRA)"
Subject: Re: [jira] [Commented] (COUCHDB-1407) JSON encoding of number changes
References: <1965486135.32404.1329156420374.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <1965486135.32404.1329156420374.JavaMail.tomcat@hel.zones.apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
I've been staying out of the fray so far, but I want to (mostly) endorse
Paul's summary and suggestion. The hear tof my arguemnt is two simple
points:
[1] JSON only defines Number. It does not define separate integer and
floating point numbers.
[2] CouchDB promises to respond to HTTP requests to PUT and GET data,
and the return value is documented to be JSON.
These two points imply that CouchDB only knows about the kinds of data
structures that JSON defines and supports, and thus can/should make no
promises about the representation of numbers beyond what you can get
from JSON..
If an application depends on the distinction between integers and
floating point values, then it is up to the person writing the
application to make sure this distinction survives. As has already been
pointed out, they can accomplish that goal by storing all numbers as
(JSON) strings and using their application to decode/eval them. This
fix requires no changes to the CouchDB code.
I would not even change the encoder to deal with decimal points and
precision. I would advocate just making sure that the documentation is
clear on this point. In particular, it is probably necessary to
document (as a breaking change that may require people to rewrite some
of their applications) the fact that 1.2 may drop trailing zeros after
the decimal point.
You cannot really promise to support different types of numbers without
radically changing the CouchDB code. You would then have to continually
fight with JSON to get it to support something that is beyond its
capabilities. Maintenance would become a nightmare. Let's try to avoid
that road....
Kevin
On 2/13/2012 12:07 PM, Paul Joseph Davis (Commented) (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207022#comment-13207022 ]
>
> Paul Joseph Davis commented on COUCHDB-1407:
> --------------------------------------------
>
> As mentioned on the dev@ thread, I'm pretty dead set against this approach. While there seems to be some sort of general consensus that storing numbers as uninterpreted bytes and repeating them back is the way to go it really misses the entirety of the issue.
>
> First, CouchDB has never claimed to pass numbers around while keeping byte identical representations. This patch attempts to change that drastically with a very large number of consequences that we haven't begun to investigate.
>
> Secondly, if we were to actually consider going this route then we'd also be obliged to start looking at every other place where we change representations internally as well.
>
> Thirdly, if we were to do that then we'd also have to get into all of the cases where we're stricter than JSON specifically allows and then try and address all of those issues as well.
>
> Basically, how about we just fix the encoder to spit out a decimal point and an appropriate amount of precision and then start documenting our round tripping limitations.
>
>> JSON encoding of number changes
>> -------------------------------
>>
>> Key: COUCHDB-1407
>> URL: https://issues.apache.org/jira/browse/COUCHDB-1407
>> Project: CouchDB
>> Issue Type: Bug
>> Components: HTTP Interface
>> Affects Versions: 1.2
>> Environment: Ubuntu 12.04 (alpha)
>> Reporter: Adam Lofts
>> Attachments: 0001-Only-validate-numbers-on-JSON-decoding.patch
>>
>>
>> JSON encoding of Number has changed from 1.0.2 to 1.2. JSON only defines Number but this change causes issues in my app because python decodes the number as an int in 1.2.
>> Test case:
>> PORT=5985
>> curl -X DELETE http://localhost:$PORT/test-floats/
>> curl -X PUT http://localhost:$PORT/test-floats/
>> curl -X PUT http://localhost:$PORT/test-floats/doc1 -H "Content-Type: application/json" -d "{ \"a\": 1.0 }"
>> curl http://localhost:$PORT/test-floats/doc1
>> Run against 1.0.2:
>> {"ok":true}
>> {"ok":true}
>> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
>> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1.0}
>> Run against 1.2:
>> {"ok":true}
>> {"ok":true}
>> {"ok":true,"id":"doc1","rev":"1-78e61304147429d3d500aee7806fd26d"}
>> {"_id":"doc1","_rev":"1-78e61304147429d3d500aee7806fd26d","a":1}
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>