[Twisted-Python] Sqlalchemy + Twisted Ideas

[Ed Suominen]

I am a new but very enthusiastic user of sqlalchemy and have been
happily banging out some code to use it. Like Valentino Volonghi (but by
no means in the same league), I am also a big fan of Twisted and want to
integrate my use of sqlalchemy into Twisted apps.

Before I get too deep into unit testing (yes, I wrote the code first,
shame on me), I'd like to get some feedback from both sqlalchemy and
twisted users about what they think of the approach in my module
database.py, which I have posted to http://edsuom.pastebin.com/555036.

A use case, for my persistent graph package that's going to rely on all
this, is posted to http://edsuom.pastebin.com/555040. Note how some
database operations are simply encapsulated into a self.transact() call
while others, involving several lines of code, are put into a local
function and encapsulated into a self.transact(thisTransaction) call at
the end of the method.

Some assorted coolness:

* You can use Twisted's deferred result mechanism or block, even on a
case-by-case basis.

* Engines are defined at the class level, for all tables and contexts.
Tables are defined, also at the class level, for all contexts. Cached
selects are defined, however, on a context-by-context basis.

* In all three cases, thread-local storage permits even cranky databases
like sqlite from complaining about connection objects created in one
thread being used in a different thread.

* Overridden attribute access is used to construct, or retrieve from
cache, the needed goodies on the fly. Advantageously, those goodies are
constructed in the context not only of the current Table (in the case of
cached select() objects) but also in the current thread.

Comments welcome -- positive, critical, or utterly disdainful!

- Ed Suominen