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