chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] SQLite3 bindings for CHICKEN 4


From: Jim Ursetto
Subject: Re: [Chicken-users] SQLite3 bindings for CHICKEN 4
Date: Wed, 12 Aug 2009 02:21:57 -0500

On Wed, Aug 5, 2009 at 9:02 AM, Thomas Chust<address@hidden> wrote:

> If, for example, you prepare a statement and forget to ever execute
> and finalize it, my sqlite3 egg will at least tell you that you have
> an unused statement lying around when you try to close the database.

sqlite3 will tell you with an error, and then permanently prevent you
from closing the database.  If that statement was executing
and you don't have a pointer to it, you've probably wedged the
database, and must abort your process.  Hopefully, no other
processes need to use the database before you can do this.
This happens all the time to me, especially at the repl.

sql-de-lite will tell you as well--if you feel the need to track statements
manually, you can simply disable the cache and unfinalized statements
will be reported as warnings when the database is closed (but they
will then be finalized, so the database is not wedged).

> Of course, having a global statement cache makes multithreaded
> programming using sql-de-lite nearly impossible anyway.

The statement cache can be disabled.

> A client side statement cache may be convenient in some situations but it
> always adds a little overhead and doesn't really belong into a direct
> database API binding, but rather into an ORM or other higher level
> layer that hides the database details.

Nearly every existing "low-level" SQLite binding that I came across
provides a statement cache: Perl, Python, Ruby, and the official
Tcl extension.  IMO, it makes it much easier for the casual user as he
does not need to track prepared statements himself--and
preparing a new statement takes absolutely *forever*.  Working with
the low-level API becomes doable, without hiding the database
details--which, to me, is exactly what you don't want to do with SQLite.

sql-de-lite provides both a low-level and a high-level API and, if
you don't like the high level API, you can disable the cache, disable
exception raising, and use it like a bare SQLite interface.

> Opening multiple database connections to the same database
> from inside the same operating system thread, like sql-de-lite
> claims it is possible, only helps if you are lucky either, since
> it may cause locking problems.

Locking problems which the interface is designed to avoid.

The fundamental difference between the two eggs seems to be:
sqlite3 expects the user to use synchronization primitives to
access a database over one single connection; sql-de-lite
expects the user to open one database connection per thread.
sqlite3 doesn't support the latter unless you handle exceptions
manually and carefully; sql-de-lite's interface is designed for
it.  And, even if you do use one connection for multiple
threads, other processes can still be locked out of the
database indefinitely in case of programming error.

I think it is useful to have two eggs with different design approaches.
Both have their strengths and weaknesses.

Jim




reply via email to

[Prev in Thread] Current Thread [Next in Thread]