3 ms·

I looked at the first two libraries listed on the landing page, and they seem to be mostly implemented in C. (The same goes for the 3rd lib, but it's SQLite bin

I looked at the first two libraries listed on the landing page, and they seem to be mostly implemented in C. (The same goes for the 3rd lib, but it's SQLite bindings, which makes sense.) This is a bit discouraging.

prirun 6y ago
I have been looking at Nim, Go, and D lately, as a follow-on to Python. Good SQLite support is something I need for HashBackup (author). Nim has a direct interface to SQLite's C API and a higher-level db_sqlite interface. The higher-level interface doesn't support prepared queries so Nim's SQLite performance on a small test is slower than Python using the sqlite3 API which automatically compiles and caches queries. The Nim binding replaces all parameters, specified with ?, with quoted values. That means: - you can't have a null-valued parameter - numbers get inserted as text (I think) - blobs are string quoted and get changed to text instead of using SQLite's X'(hex)' blob notation All returned values from db_sqlite are strings. If you want integers, you have to parseInt() the column. I do like that Nim's db_sqlite interface is very simple so that you can still use the lower-level sqlite interface with the same db connection. So at least I could cache prepared queries if I wanted, but I have to do the work. Checking out Go's SQLite interface, there are some issues posted on the repo (mattn/go-sqlite3) about performance problems because Go uses cgo for SQLite. Haven't test that yet. Since the SQLite module was listed on the front page of Janet's site, I decided to check it out. It, like all the other C code I looked at in the project, is rather beautiful, and that's not a compliment you see very often about C code, my own included. The SQLite interface handles multiple types, including nulls, blobs, and numbers (everything is a float, I'm guessing because that's how Janet implements all numbers). It appears to not cache prepared statements (that would probably be a big performance boost), but does allow parameter substitution by name. If you want to see some really nice C code, check out this project!

prirun 6y ago

I have been looking at Nim, Go, and D lately, as a follow-on to Python. Good SQLite support is something I need for HashBackup (author). Nim has a direct interface to SQLite's C API and a higher-level db_sqlite interface. The higher-level interface doesn't support prepared queries so Nim's SQLite performance on a small test is slower than Python using the sqlite3 API which automatically compiles and caches queries. The Nim binding replaces all parameters, specified with ?, with quoted values. That means: - you can't have a null-valued parameter - numbers get inserted as text (I think) - blobs are string quoted and get changed to text instead of using SQLite's X'(hex)' blob notation All returned values from db_sqlite are strings. If you want integers, you have to parseInt() the column. I do like that Nim's db_sqlite interface is very simple so that you can still use the lower-level sqlite interface with the same db connection. So at least I could cache prepared queries if I wanted, but I have to do the work. Checking out Go's SQLite interface, there are some issues posted on the repo (mattn/go-sqlite3) about performance problems because Go uses cgo for SQLite. Haven't test that yet. Since the SQLite module was listed on the front page of Janet's site, I decided to check it out. It, like all the other C code I looked at in the project, is rather beautiful, and that's not a compliment you see very often about C code, my own included. The SQLite interface handles multiple types, including nulls, blobs, and numbers (everything is a float, I'm guessing because that's how Janet implements all numbers). It appears to not cache prepared statements (that would probably be a big performance boost), but does allow parameter substitution by name. If you want to see some really nice C code, check out this project!