At 01:58 AM 4/3/02 +0200, Magnus Lyckå <magnus@thinkware.se> wrote:
So, we expect to see the announcement of a DB-API 2 complient SQLite driver any day then! :-)
I wish ! :-) Actually, I'd love to try it. But maybe there are some DB-API-2 experienced folks out there who could do this in their sleep (if they ever get any time to sleep). The SQLite C API is really that simple -- one data structure pointer representing an open database, 3 functions (open_db,close_db,execute_sql) and 1 callback (to handle the rows in the result set). Of course I'm being a bit silly -- It takes lots of work to put any robust piece of software together. I'll probably take a stab at it but I wanted to see if the Python/Zope world is even interested.
I'd say a small subset [of SQL92], or perhaps sideset:
Yet but probably sufficient for a small, local relational data store.
But it seems a bit closer to SQL than GadFly...and apart from typelessness it seems to support rather extensive SELECT statements. It might be a very useful thing I guess. There are plenty of cases where installing an RDBMS is overkill.
Yes, that's what I thought; for small amounts of data a large, fully featured RDBMS is overkill. Yet, often, flat tables are not the solution either. Even for small data stores the benefits of the relational model still apply and flat files can be a real pain when the data relationships are complex. For instance, as a simple use-case, consider the frequent, common software application need for storing configuration data. Often, this data is stored in a collection of flat files. The amount of data in these files may be relatively small but the data relationships can still be very complex. As we all know a collection of flat files doesn't directly provide the mechanism to implement these data relationships. But most RDB software is far too large to justify using this well established data technology for configuration data. I have often thought it would be beneficial to have a small, low-overhead SQL engine as a software component. I am suggesting SQLite as a candidate.
If it lifts entire tables into RAM it might be very memory hungry for large databases.
This is an excellent and important observation. One of the reasons I'm suggesting SQLite is that it's memory model is, fortunately, more sophisticated than simply lifting entire tables into RAM. To quote from The Architecture Of SQLite (http://www.hwaci.com/sw/sqlite/arch.html): "The B-tree module requests information from the disk in 1024 byte chunks. The page cache is responsible for reading, writing, and caching these chunks at the behest of the B-tree module. The page cache also provides the rollback and atomic commit abstraction and takes care of reader/writer locking of the database file. The B- tree driver requests particular pages from the page cache and notifies the page cache when it wants to modify pages or commit or rollback changes and the page cache handles all the messy details of making sure the requests are handled quickly, safely, and efficiently."
So, how active is the mailing list? And how good? I saw a subscribe link, but no archive (maybe I just missed it.)
When you sign up you are taken to a page that lets you have the option of getting to the archives. The SQLite mailing list is a Yahoo eGroup forum so to get at the archives you have to sign up with Yahoo -- oh well. Thanks for commenting, Bill "The commandments of the LORD are right, bringing joy to the heart. The commands of the LORD are clear, giving insight to life . . . For this is the love of God, that we keep His commandments. And His commandments are not burdensome." (Psalm 19:8, 1John 5:3) <http://torahteacher.com/>torahteacher.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.343 / Virus Database: 190 - Release Date: 3/22/02