I'm not sure if this is a terrible idea or not... (As I've never tried it, but got the idea while following this thread) But how about encoding with protocol buffers when storing into couch... There are a few protocol buffers JS libraries that could be used to marshall values within MapReduce, list, show, and other functions... but then you possibly run up against spidermonkeys precision issues, at least there would be no Erlang to Spidermonkey round trip issues. With the amount of data you seem to be concerned about, it might even help with space, especially if you made list/show functions that streamed in protobufs. Just not sure how viable or practical it would be.
I know I've run into this issue before and have conceded to store FP as an array of 2 int values (mantissa and exponent) as well as encoded with strings. However I've not needed to do any Maths within CouchDB, just pure storage. Sent from my iPhone On Feb 20, 2013, at 12:03 AM, "Benoit Chesneau" <[email protected]> wrote: > On Tue, Feb 19, 2013 at 6:33 PM, Jens Alfke <[email protected]> wrote: > >> As for alternative data formats, there are a lot of them around, and I don’t >> see that EDN would have an advantage over any of the others that are better >> known and more widely adopted, like YAML. Changing away from JSON would be a >> compatibility nightmare, anyway (speaking as the author of a >> Couch-compatible replication engine.) > > > edn has the advantage to provide you a way to describe the number by > annotating it somehow. So it doesn't solve the "maths" problem but > would solve the representation or at least make it a little better > when for example you expect a real with 2 decimals you will get it > instead of having X non expected decimals. > > Going to a new format would be for sure a challenge but not that big > if apache couchdb and compatible product respect the content-type > header. And it will be a user choice. > > - benoît
