couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Tue, 14 Feb 2012 08:38:57 GMT
On Tue, Feb 14, 2012 at 5:35 AM, Paul Davis <> wrote:
>> In other words, instead of an experimental encoding trick, CouchDB
>> used well-known decimal types. Would that change your opinion at all?
> Hypothetically I wouldn't reject it out of hand. Hypothetically, if
> something were to exist and were significantly less intrusive than a
> tagged binary then maybe.

I would like to define "intrusive." That would more clearly show
whether this exercise is worthwhile.

> Though I hypothesize that nothing like this
> exists. Erlang's type system is basic and has no notion of operator
> overloading or otherwise.

That is a big issue. Even if something exists, I admit it pushes this
discussion out of scope regarding "what to do about the 1.2 release."

I found which says it is
implemented from which seems to be
created at IBM.

> Thus, at best, we provide mathematical
> routines for internal use but nothing else changes much. It'd still be
> some sort of tagged value that we'd have to use function calls to do
> any sort of mathematical manipulation if the need were to arise.

Couch rarely manipulates these numbers. It's basically parsing JSON so
it can update a _rev key

Couch processes numbers from JSON when a map function emits a number
in the key. It sends JSON to couch over stdio, and couch has to put it
in the index. So--hypothetically--Couch should either (a) parse to
float instead, or (b) have greater/less-than support, with no speed
regression. (I think I recall that the collation functions are
straightforward, pattern matching could trigger this alternate
comparison function.)

Am I missing any other situations where couch must both parse a number
to process it and also to re-encode it?

> Also note that while JavaScript might be a PITA, its not the only view
> server and other view servers (specifically Erlang) will have to deal
> with this.

I'm not sure what you're getting at. The whole point is to make The
Perfect JSON Encoder. So if I store {"one":1, "one.point.oh":1.0} then
the line printed on stdio to the view server would contain {"one":1,
"one.point.oh"1.0} and Javascript/JSON2/whatever is free to parse that
however it likes.

Iris Couch

View raw message