On Wed, Aug 5, 2009 at 9:02 AM, Thomas Chust<[email protected]> 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 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
