The whole web/WSGIKit/Rails thing has me thinking about the steps to get an application up and running, and I want to make that work really easily. I feel like WSGIKit does that fairly decently right now (no documentation, but that will come soon!) -- but I think SQLObject is also a key component in the equation (for any framework that uses SQLObject). So I've been thinking about how to make it easier to manage.

The first thing I've done is ConnectionHub, which will become the "default" connection. It's just a way to register a connection after class creation, so you can (probably based on configuration) connect all your tables to the same database, after the modules have been loaded. It will look something like:

import sqlobject

sqlobject.hub.processConnection = connectionForURI(
    'mysql://localhost/testdb')

But frameworks can probably put in that glue on their own, so you can just define your classes with no boilerplate configuration or glue. This is something people are already doing in some projects (like sqlo for Zope 3 -- a project which seems entirely invisible to Google), but this turns it into a supported pattern. And it's just plain easier. You can register connections globally (processConnection) or per-thread (threadConnection).

The other thing I've started work on is a sqlobject-admin command-line client. The program can find your SQLObject classes and create and drop tables, as well as show you the SQL CREATE statements and check your data definitions against the actual tables in the database (an imperfect comparison, but at least it can show obvious differences).

Still to be written for sqlobject-admin is something that records the SQL CREATE statements and gives them a "version" (which doesn't necessarily match with your software's version), and also stores that version number in the database (in some special table). Later when you do development elsewhere and have to bring a database in sync with the latest version of your code, the tool will be able to query the database for its version and run upgrade scripts (that you hand-code). The operations are actually pretty crude, but it's mostly just to codify a process that allows for more agile and automated database evolution.