Michael Bayer wrote:

At least someone else thought it was a good idea too ;). It's also all very similar to Zope.

I think that would be easy enough. All that is setup early is the transaction container; nothing is automatically added to it. So @transactional could just add a transaction to the container (presumably everything would otherwise be autocommit, or perhaps automatically rolled back?)

Presumably what you really want to do is add-this-transaction-if-it-isn't-there-already all over the place. For instance, if you've already started a transaction in middleware, I don't think you'll need to start another transaction. Unless you have subtransactions, which I suppose is possible.

Hmm... I believe paste.exceptions should do this already, even if an exception is raised after start_response is called, as long as it is raised before the app_iter is returned. If it's after the app_iter, then you've somehow escaped the stack, which doesn't much concern me ;)

So as middleware I think it should be fine. If you want to catch a problem with the commit and handle it gracefully, I think you can just do your own commit in your code (and the middleware commit will just commit what little happens after that).

And of course, what you put in as a transaction is up to you. You could put in some object which uses whatever flags you want to actually pass through a commit or else just ignore it.

I dunno... I think if we can get this in place, then a whole lot of things are going to become simpler. But there also still has to be wrappers like SAContext from this fairly low-level stuff to a particular framework.