shouldn't integer types be returned as integers (and not strings?)

[erf]

im doing this:

var dblite = require('dblite'),
            db = dblite(':memory:');
        db.query('CREATE TABLE IF NOT EXISTS test (id INTEGER PRIMARY KEY, textValue TEXT, intValue INTEGER)');
        db.query('INSERT INTO test VALUES(null, ?, ?)', ['some text', 123]);
        db.query('SELECT * FROM test');

and expect to have the intValue returned as an Integer and NOT a String.

i know i can do this:

     db.query('SELECT * FROM test', {
            id: Number,
            textValue: String,
            intValue: Number
        });

but maybe i don't want object notation, also its more to write..

but i do like object notation, and when you enable the -header option you get the rows automatically as objects with names of the columns, just like in sqlite3-node, but the Integeres are strings, if you dont set this explicitly..

this is the output i get in both cases:

[ [ '1', 'some text', '123' ] ]
[ { id: 1, textValue: 'some text', intValue: 123 } ]

[WebReflection]

Did you Read all answers to Your questione in the README.md file already?

[WebReflection]

So here a better answer. What you expect might be wrong because SQLite deals with 64bits while JavaScript still uses 32bit integers.

What's written already and explained in README.md is that

• SQLIte and JavaScript have different meaning of type plus ids are ids ... I don't know why you need them to be integers but you can use the notation to map values without problems. If you don't want to, I will not change this so feel free to find alternatives.
• dblite is not a replacement for node-sqlite3 ... is a different beast that works already in Arduino YUN, ArchLinux, and all developer boards with limited amount of CPU and RAM. Too fancy magic does not belong here, specially because this is a wrapper for the shell, not a C binding. Feel free to use node-sqlite3 for your needs
• if the problem is more to write then use shortcuts such '' for string type, and I might double check if I have 0 or numbers for the number type.

Problems dblite solves are:

• no gyp compilation needed, no need for a remote pre-built binary, not a binary at all indeed
• as fast as possible robust wrapper for SQLite-shell sessions driven in a JavaScript fashion and through JavaScript
• a straight forward, no magic, WYSIWYG parsing logic that can be improved, when/if needed, through the fields object which is a simplification you seem to not appreciate (but others did)

If you want to improve dblite with a push request after testing it and its performance against node-sqlite3 and without degrading them, I'll be more than happy to review and accept that.

Thank You anyway for your interests in dblite.

[erf]

i was thinking you could add an option field (like '-header') to automatically do a JSON.parse on all fields you query.

[erf]

you could do a try/catch beforehand to check if its a valid json string, like discussed here: http://stackoverflow.com/questions/3710204/how-to-check-if-a-string-is-a-valid-json-string-in-javascript-without-using-try

[WebReflection]

an JSON.parse per each field within a try/catch is a performance killer that will never land here. You can do that by your own, I am not planning to ship a footgun with dblite, sorry, also 64bits integer, there's no JSON that you can catch able to preserve that consistency, just a broken integer. don't want/won't fix

The only thing that might happen is a helper able to give you fields type per a specific table but I have no idea who on earth would need that when you can just use an object and specify any revival you want, same as you would do with JSON objects.

[erf]

ok, yeah that makes sense. thanks for explaining!