At 01:58 AM 4/3/02 +0200, Magnus Lyckå <[EMAIL PROTECTED]> 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 (

"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 

>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,

"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)    <>

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.343 / Virus Database: 190 - Release Date: 3/22/02

Reply via email to