[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Differences between Lua-Sqlite3 and LuaSQLite
- From: Joshua Jensen <jjensen@...>
- Date: Fri, 20 Mar 2009 11:10:19 -0600
----- Original Message -----
From: Doug Currie
Date: 3/19/2009 11:04 AM
No, but having a definitive "complete" library would be nice. I want to
have the best library at my disposal. But despite decently knowing my
way around SQLite, I can't identify which Lua library I should use. I
love how Asko always makes a case for his libraries with a big
comparison with the competition. It is his opinion, but at least I
better know why he thinks his library is better than the others.
On Mar 19, 2009, at 12:49 AM, Joshua Jensen wrote:
Can the authors tell me what makes one better than the other? Does
Lua-SQLite support more SQLite 3 features, because it is newer?
Probably, but if it is a feature you don't need it doesn't matter.
The history of luasqlite is that Tiago and I each had a sqlite (v2.x)
library, and we combined efforts for sqlite3. At the time we felt we
got the feature set "right," at least for us. Thomas Lauer contributed
most of the documentation, and I massaged it and converted it to POD
format. We tend to update the library when we need it for projects,
which most recently, but not very recently, has been my doing.
It sounds like one more merger (if needed) of Lua-Sqlite3 functionality
would give us a one stop shop for a complete Lua SQLite library with
documentation both in User's Guide and Reference Manual form.
LuaSQLite appears to have chosen the 'return the error per function
call' approach. Lua-Sqlite3 uses error(), and error handling would need
to be handled in pcall().
* Lua-Sqlite3 has a more convenient (IMHO) interface where I can
write things like stmt:bind(valueA, valueB):exec(). The equivalent
in Lua-SQLite is 3 statements: stmt:bind_values(valueA, valueB);
It is difficult to find a good balance between convenience and
robustness. Chaining prepare, bind, execute, reset is convenient, but
omits error checking and recovery. My projects are usually production
applications, and error recovery and reporting are critical, so the
convenience stuff is not so important to me. Nevertheless I spent some
time making sure that one-off queries were fairly easy, and that the
prepared-statements used were cleaned up properly depending on whether
they are persistent or transient statements.
The P4Lua library chooses to do both. Setting p4.exception_level will
cause it to use either the 'return the error per function call' approach
or the 'exception handling' method.
Both sqlite libraries (and others) are being used regularly. Perhaps
others on the mailing list will have reasons for choosing one over
another. I use luasqlite because it does what I need and I am more
familiar with it.
I converted some of my scripts to LuaSQLite. The APIs are ALMOST
identical. I had to change rows() to nrows(), bind() to bind_values(),
and split the exec() call out into step() and reset(). Pretty easy.