[I apologize if this comes through twice. I decided to re-send
directly to the list because Gmane apparently isn't going to
deliver my original.]
I've been getting to know SQLite over the weekend. It's very cool.
I need to share a database between a few processes -- one reader
and a couple of concurrent writers -- where a full-blown RDBMS
would be too heavy. I'm storing instructions for delivery
addresses in an email system, so the database will be frequently
SELECTed and (comparatively) seldom updated.
My solution, which seems to work well, is a poor man's blocking
scheme where access to the database loops until successful:
while ! sqlite $DB_FILE "BEGIN TRANSACTION; $sql; COMMIT;" \
>/dev/null 2>&1; do
continue
done
For any error other than SQLITE_BUSY, however, I'd like to report
failure to the calling process; but I can't do this because the
sqlite binary exits 1 for *any* error:
$ sqlite tmp.db 'insert into foo values (234,23423);'
SQL error: database is locked
$ echo $?
1
$ sqlite tmp.db 'inserblt into foo values (234,23423);'
SQL error: near "inserblt": syntax error
$ echo $?
1
$ sqlite tmp.db 'insert into foo values (234,23423, "no more values");'
SQL error: table foo has 2 columns but 3 values were supplied
$ echo $?
1
I've also noticed that DBI::err returns 1 from DBD::SQLite no
despite the exception, as well, so I had to implement a similar
idiom in Perl for the reading process. I suppose I could parse
DBI::errstr in this case, but, ack.
Why doesn't the API return separate codes for each of the SQLITE_*
error constants? I'd submit a patch to accomplish such, but I
can't figure out how to get to the sqlite binary source through all
the libtool stuff.
Thanks for any insight.
--
[EMAIL PROTECTED] (Andrew A. Raines)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
