couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: [VOTE] Apache CouchDB 1.2.0 release, first round
Date Tue, 14 Feb 2012 12:13:27 GMT
I am going to halt this thread here, and split it in to two:

   - Issues blocking the 1.2.0 release
   - Roadmap for the 1.3.0 release

Please move anything to do with fixing regressions and release blockers to
the 1.2.0 thread.

Please move anything to do with what we want to do with number handling in
to the 1.3.0 thread.

Thank you.

On Tue, Feb 14, 2012 at 8:38 AM, Jason Smith <jhs@iriscouch.com> wrote:

> On Tue, Feb 14, 2012 at 5:35 AM, Paul Davis <paul.joseph.davis@gmail.com>
> 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 https://github.com/tim/erlang-decimal which says it is
> implemented from http://speleotrove.com/decimal/ 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message