Hi, Paul. Thank you very much for this!
IMHO, in future, Couch might use a BigDecimal type when working with
documents' numbers. It never *computes* anything with those numbers,
so performance should be okay; it's just to preserve the user's data
through a decode/encode round-trip.
For now, you
Hi Everyone-
I have been using CouchDB for several years and I absolutely love working
with it most of the time. Thanks to everyone who has made it such a joy to
work with. There are however a few consistent situations where I run into
trouble and that I would like to fix if possible. I have a
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
Hi Roger,
On Feb 13, 2012, at 10:09 , roger.moff...@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
Excellent analysis Paul.
I'd say we go with the patch for 1.2.0 and beyond.
Cheers
Jan
--
On Feb 13, 2012, at 07:55 , Paul Davis wrote:
So yeah. Numbers are hard.
Firstly, anyone that mentioned RFC 4627 or JavaScript behavior is
walking down a path entirely orthogonal to the issue at
On Feb 13, 2012 1:10 AM, roger.moffatt
roger.moff...@gmail.com@roger.moff...@gmail.com
gmail.com roger.moff...@gmail.com wrote:
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
On Mon, Feb 13, 2012 at 10:55 AM, Randall Leeds randall.le...@gmail.com wrote:
A very rigorous approach might be to work with the tokenized, but not
decoded, JSON so that numeric field values could be passed verbatim. For
1.2 I'd just like to see the integer regression patched.
Catching up on
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-1407:
---
Attachment: 0001-Only-validate-numbers-on-JSON-decoding.patch
This is the patch I just
Hi,
Just a quick check (since I am not entirely familiar with this).
Does this also imply that the couchdb 'on disk' format needs a version increase?
(since the term representing numeric fields changes?)
Best regards,
Jeroen Janssen
On Mon, Feb 13, 2012 at 4:46 PM, Filipe David Manana
On Mon, Feb 13, 2012 at 4:04 PM, Jeroen Janssen
jeroen.jans...@gmail.com wrote:
Hi,
Just a quick check (since I am not entirely familiar with this).
Does this also imply that the couchdb 'on disk' format needs a version
increase?
(since the term representing numeric fields changes?)
I
On Mon, Feb 13, 2012 at 3:09 AM, roger.moff...@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
I'm really not a fan of this. Rather than simplify the situation it's
adding a whole big set of questions on what format we have in a large
number of API end points. Seems like we should just worry about
documenting how our JSON decoder/encoder works and leave it at that.
Last night while
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13207022#comment-13207022
]
Paul Joseph Davis commented on COUCHDB-1407:
As mentioned on the dev@
On Mon, Feb 13, 2012 at 6:26 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Mon, Feb 13, 2012 at 3:09 AM, roger.moff...@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
On Mon, Feb 13, 2012 at 12:32 PM, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Feb 13, 2012 at 6:26 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Mon, Feb 13, 2012 at 3:09 AM, roger.moff...@gmail.com wrote:
I've been following this thread with interest and concern.
None of you
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
[
https://issues.apache.org/jira/browse/COUCHDB-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13207066#comment-13207066
]
Kevin R. Coombes commented on COUCHDB-1407:
---
I've been staying out of the fray
On Mon, Feb 13, 2012 at 6:52 PM, Kevin R. Coombes kevin.r.coom...@gmail.com
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,
[
https://issues.apache.org/jira/browse/COUCHDB-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Bonhage resolved COUCHDB-1332.
--
Resolution: Fixed
Fix Version/s: 1.1.2
1.3
On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
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
On Mon, Feb 13, 2012 at 7:23 PM, Jason Smith j...@iriscouch.com wrote:
On Mon, Feb 13, 2012 at 5:26 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
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
21 matches
Mail list logo
