[Zope-DB] Re: [DB-SIG] SQLite as a Light DB component for Zope and Python
Wed, 03 Apr 2002 09:16:47 +0200
Magnus Lyckå wrote:
> At 17:54 2002-04-01 -0800, William Trenker wrote:
>> but a greenhorn at extending Python yet I had a
>> crude but working Python extension module for
>> SQLite up and running in 2 days
> So, we expect to see the announcement of a DB-API 2
> complient SQLite driver any day then! :-)
>> Implements a large subset of SQL92.
> I'd say a small subset, or perhaps sideset:
If you campare it with OCELOT you are right but you have to compare it
> SQLite implements the follow syntax:
> · BEGIN TRANSACTION (END COMMIT ROLLBACK)
> · COPY
> · CREATE INDEX
> · CREATE TABLE
> · CREATE VIEW
> · DELETE
> · DROP INDEX
> · DROP TABLE
> · DROP VIEW
> · EXPLAIN
> · expression
> · INSERT
> · ON CONFLICT clause
> · PRAGMA
> · REPLACE
> · SELECT
> · UPDATE
> · VACUUM
> (Or at least that's what the language reference at
> http://www.hwaci.com/sw/sqlite/lang.html says.)
> No GRANT / REVOKE or any other kind of security.
> It seems to be a plain single user thingie.
> No ALTER TABLE, SET TRANSACTION etc. Ok, these aren't
> actually in Entry SQL 92, but everybody else has them...
> And COPY, PRAGMA, REPLACE, VACUUM, ON CONFLICT etc is
> not in any SQL standard I know of.
> It violates SQL92 in a number of ways it seems. For
> inststance, it's typeless (like GadFly) which means that
> for instance "00" == "0". There are a lot of error
> checking in SQL that this engine won't do.
> SQLite ignores checks in CREATE TABLE and has no foreign
> 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
>> Small memory footprint: less than 20K lines of C code.
> Erh? Measuring memory footprint in kLoC seems a bit like
> measuring mass in meters. Although according to the 2.4.0
> release notes at freshmeat it seems the binary image needs
> less than 200kB! Question is how much RAM that actual data
> requires. If it lifts entire tables into RAM it might be
> very memory hungry for large databases.
>> Four times faster than PostgreSQL. Twice as fast as SQLite 1.0.
> Yea yea, it just depends on what you measure. And how.
> PostgreSQL is infinitely faster on the features SQLite
> doesn't support... Benchmarking is a bit too complex to
> just describe like a scalar like that.
>> The author, <mailto:email@example.com>D. Richard
>> <mailto:firstname.lastname@example.org>Hipp, is a computer science Ph.D. who knows his
>> stuff. This is not green software, it is well designed and tested.
>> It was first released in May 2000 and is very actively updated and
> So, how active is the mailing list? And how good? I saw
> a subscribe link, but no archive (maybe I just missed it.)
The SQLite mailing list is very active. I am a list member.