mariano/node-db — pull request #13 by imkira (2012-09-12 02:46:51+00:00)
Title: handle BIGINTs as strings (pre libuv)

First of all, I apologize for submitting a commit that is based on your commit supporting libuv (806d7b47fe036bdafb4eb3770ed3aea9abaa972b).
Nevertheless, the changes in this pull request should be easily merged in your repo as it is now.

Now into the problem.
I have been struggling with the need of BIGINTs. However, the current version of node-db/node-db-mysql handle it as INTs and cast them to Javascript numbers which, like all we know, are prone to precision inaccuracies for after the 53th bit.

I have been working around by using CAST(xx AS CHAR) in SELECT commands but, not only it is cumbersome, it is not possible to do the same thing for getting the insertIds for INSERT commands (which get internally converted from uint64_t to v8::Number).

What I propose with this commit is to treat insertId, affectedRows, warning, indexes (emit.each) and data from BIGINT columns as v8::String. I am doing this in a forceful manner, and that is where my doubt lies.

1. Should we allow the "cast" argument to be applied a list of columns? : As of the current version of node-db, since there is no way to disable casting by column name (only globally by setting the cast parameter to false in the call to select/insert/etc.), I thought it would be easier to treat all BIGINTs as strings.
2. The other approach would be to look at the number and check whether it is safely representable in v8::Number and convert it to v8::String only if it is not. However, I think it would be kind of "weird" to get columns having a mix Number and String, so I vote that option down.
3. The other approach, which is like I followed (also for being the easiest) is to treat BIGINTs as string. If the return is fixed type, it is easier to handle because the user must be aware of precision issues. Javascript non-strict comparisons against numbers also apply correctly (eg. "33" < 4) and parseInt also works (of course with precision limitations).

Personally I believe 3 is the best solution, as there are not that many projects using BIGINT and even if they are I believe developers must be aware of the limitations of javascript numbers.

What is your opinion?

By the way, there is a similar https://github.com/felixge/node-mysql/issues/207