On Tue, Feb 14, 2012 at 5:35 AM, Paul Davis <[email protected]> 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
