APSW is not DBAPI compliant but it's close enough
Note that I do document how APSW differs from DBAPI.
http://www.rogerbinns.com/apsw.html#dbapinotes
APSW is very nice.
Thanks :-)
I've used it and PySQLite and I'd recommend APSW. It's "thinner".
Note that it is almost impossible to do a DBAPI compliant interface
to SQLite. For example DBAPI requires providing time types which
SQLite doesn't natively provide. A wrapper has to "fake" it. Similarly
various transaction methods must be provided (commit, rollback etc)
which are almost impossible to implement without sniffing the SQL. Also don't kid yourself about how easy it is to move from one
DBAPI compliant system to another. Pretty much all projects provide
their own layer as glue between their code and the DBAPI drivers.
If you want DBAPI compliance then use pysqlite. It tries really hard to fill in the necessary pieces that SQLite doesn't have.
On the other hand if you only want to use SQLite then use APSW. It doesn't hide anything and gives you full access to all SQLite functionality. You can also do things like define your own collations and functions in Python.
Where applicable APSW does use DBAPI conventions and names.
As for a web front end, I suggest you make an XML-RPC wrapper around your database and then access that from whatever you want to use for your web stuff.
As an example of something I worked on in the past, I implemented a PHP front end using Smarty templates and a Python process on the backend which was talked at using XML-RPC. The Python process did everything including managing sessions and storing the templates. The PHP/Smarty code dealt with display.
This let me use each environment for what they were best at and decoupled them. I could also have done other front ends such as a command line, which comes in really handy if you need to automate some processes.
Roger
