INTEGER type parsing incorrectly about sqlite3

[DjDeveloperr]

Fix released in 0.2.5

[iuioiua]

Legend! Thank you 🙏🏾

[DjDeveloperr]

I think that's because it's parsing all integer type columns as 32-bit integers. I will fix this asap

[Hexagon]

@DjDeveloperr

This problem seem to be back in 0.8.2

CLI:
SELECT MAX(period) FROM spotprice
1678572000000

Deno sqlite3 0.8.3
prepare('SELECT MAX(period) FROM spotprice').values() // also tested with .all(), also tested with <number> and <bigint> like in the test cases, to no avail
[ [ -760212736 ] ]

[DjDeveloperr]

@Hexagon See doc.md. It's a performance optimization to always prefer 32-bit integers over 64-bit. SQLite API does not differentiate between both in value type, hence the preference.

If you want to serialize as 64 bit either set int64: true in DB options or temporarily set it in DB's property to avoid performance deopt.

Performance issue is because the FFI API cannot use BigInts in fast path, but this may change in future, so both options will become performant.

[Hexagon]

@DjDeveloperr Sorry about that! I searched the docs and googled and somehow missed that the option were listed at top of documentation 😅

However, this got me thinking. Is there really any performance gain from having this error prone option defaulted to int32?

Afaik both sqlite and javascript handle 64bit integers (and nothing above that) ootb. Wouldn't it be possible to change

sqlite3/src/statement.ts

Line 74 in 33946c2

if (ty === SQLITE_INTEGER && !int64) return sqlite3_column_int(handle, i);

to

if (ty === SQLITE_INTEGER) return sqlite3_column_int64(handle, i);

and drop this clause (containing a possibly slow bignum check) altogether

sqlite3/src/statement.ts

Line 83 in 33946c2

case SQLITE_INTEGER: {

[DjDeveloperr]

sqlite3_column_int is faster than sqlite3_column_int64 because the latter makes a heap allocation to store the result value as 64 bit integers are not directly supported by V8 Fast API yet. It's just an implementation detail behind the FFI API, which is likely going to change in future as returning 64 bit numbers as BigInts may become possible via Fast API, at least that's the plan.

[Hexagon]

I see, thanks for taking time to answer 👍