2009/8/12 Jim Ursetto <[email protected]>: > 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. > [...]
Hello, when I first wrote my SQLite3 bindings, it was not easily possible to prevent that problem without using a statement cache, which I didn't want to do, and I decided it was, although annoying at times, not big enough a problem to worry about very much. The situation is similar to file I/O operations: If you don't want to see errors when closing the file descriptors, just terminate the process instead and everything will be cleaned up as well. This also works flawlessly with SQLite3 databases. Since recent versions of SQLite3 contain facilities to iterate over all prepared statements associated with a database, I could actually make the finalize! routine of my SQLite3 egg clean up remaining statements as well when closing a database. I think I will make that change and also move to the sqlite3_prepare_v2 API for preparing statements, which is less error prone. But I still think an error should be raised by finalize! when orphaned statements are found. > [...] >> 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. Hmm, I'll have to take a closer look at the code, but I think it is technically impossible to prevent all the locking problems I can imagine here, because the locking facilities employed by SQLite3 at the operating system level just don't have a finer granularity than operating system threads. > [...] > 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. > [...] This is not a valid argument in my eyes. Anything can happen in case of programming error. A database lockout can, for example, easily happen when an exclusive transaction is not terminated and the process keeps running. > [...] > I think it is useful to have two eggs with different design approaches. > Both have their strengths and weaknesses. > [...] Yes, having a choice is usually not bad :-) cu, Thomas -- When C++ is your hammer, every problem looks like your thumb. _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
