Hi Daniel, I think you won't be able to do the padding inside a
(JavaScript) view because at that point you'll already be working with
a floating point number, right?
Adam
On Mar 22, 2009, at 6:23 PM, Daniel Friesen wrote:
The easiest way to check should just be to throw a few documents
with really large numbers in them.
Also do some views, I think the real issue will be the standard
floating point number limitation inside of JavaScript.
If you have numbers that are too large, the catch all way to handle
that would probably be to use a string instead and left 0 pad
numbers. Though you could probably do that inside of a view itself.
~Daniel Friesen (Dantman, Nadir-Seen-Fire)
Paul Davis wrote:
IIRC, the JSON RFC either doesn't mention limits whatsoever or only
mentions that there is no limit.
A quick glance at mochijson2.erl which is CouchDB's JSON decoder
looks
like its using list_to_integer for its conversion routine. The docs
at
[1] on list_to_integer don't mention limits. I'm not at all certain,
but I think that erlang has builtin large number support so it may
Just Work ™. But tracking down any caveats on list_to_integer/1
should give you what you need.
HTH,
Paul Davis
[1] http://erlang.org/doc/man/erlang.html
On Sun, Mar 22, 2009 at 6:06 PM, Evan McLean <[email protected]>
wrote:
Is it documented anywhere what the minimum and maximum values for
an int
are in couchdb and/or json?
Based on a 32 bit integer?
I had a quick scan through the json RFC and couldn't find anything.
How would you go about efficiently handling very large numbers,
especially if you wanted to use them in (sorted) keys?
E.
