Ian Bicking wrote:

This would be pretty much ideal, and would satisfy my use cases very well. It would also allow framework authors to build in support for any ORM / database layer in an agnostic way, sort of like the Buffet API does for templating systems.

Then, we could also create a simple WSGI middleware for Pylons that gives it TurboGears-like automatic transaction start/commit/rollback on a per request basis. Only, we could make it configurable so that it didn't happen on read-only operations. All of this would be ORM / database layer agnostic, which would be very nice indeed.

The big issue for me with SAContext right now is that it uses a BoundMetaData and expects you to know your dburi "up-front" as it were. I don't like having my model tied to my configuration system. I'd rather have my model fetch its configuration from some third party source, such as this new package we are discussing, so that I can create desktop applications, command line utilities, etc. that share my pylons application's model, without having to ship pylons or a pylons configuration file. The last thing that Ian requests here would let me do that to a certain extent:

from db_buffet_api import config from sacontext import SAContext

sac = SAContext(dburi=config.dburi)

So, I am a big +1 on such a beast.