62 messages in com.googlegroups.pylons-discussRe: Turbogears now based on Pylons!
FromSent OnAttachments
Spider27 Jun 2007 06:22 
rikl...@public.gmane.org27 Jun 2007 08:00 
Jonathan LaCour27 Jun 2007 08:10 
anderbubble27 Jun 2007 09:13 
Mark Ramm27 Jun 2007 12:39 
Mike Orr27 Jun 2007 13:45 
Mark Ramm27 Jun 2007 14:49 
Ian Bicking27 Jun 2007 14:56 
Jonathan LaCour27 Jun 2007 15:26 
Noah Gift27 Jun 2007 15:38 
Ian Bicking27 Jun 2007 15:41 
Mike Orr27 Jun 2007 15:45 
Jonathan LaCour27 Jun 2007 16:01 
Mike Orr27 Jun 2007 16:44 
Mike Orr27 Jun 2007 16:55 
Mark Ramm27 Jun 2007 17:06 
Uwe C. Schroeder27 Jun 2007 17:23 
Mike Orr27 Jun 2007 18:55 
Michael Bayer27 Jun 2007 20:46 
Michael Bayer27 Jun 2007 21:00 
Michael Bayer27 Jun 2007 21:09 
Michael Bayer27 Jun 2007 21:27 
Uwe C. Schroeder27 Jun 2007 22:40 
Mike Orr27 Jun 2007 23:09 
Mike Orr27 Jun 2007 23:40 
Uwe C. Schroeder28 Jun 2007 00:46 
Wichert Akkerman28 Jun 2007 00:54 
Mike Orr28 Jun 2007 01:33 
Uwe C. Schroeder28 Jun 2007 01:50 
Jonathan LaCour28 Jun 2007 05:55 
Jonathan LaCour28 Jun 2007 06:58 
Michael Bayer28 Jun 2007 07:12 
Michael Bayer28 Jun 2007 07:20 
Michael Bayer28 Jun 2007 07:27 
Michael Bayer28 Jun 2007 07:34 
Jonathan LaCour28 Jun 2007 07:53 
Ian Bicking28 Jun 2007 08:45 
Michael Bayer28 Jun 2007 09:31 
Cliff Wells28 Jun 2007 09:35 
Alberto Valverde28 Jun 2007 10:16 
Alberto Valverde28 Jun 2007 10:29 
Jonathan LaCour28 Jun 2007 10:32 
Ian Bicking28 Jun 2007 10:45 
Alberto Valverde28 Jun 2007 11:01 
Alberto Valverde28 Jun 2007 11:15 
Uwe C. Schroeder28 Jun 2007 11:32 
Mike Orr28 Jun 2007 11:52 
Alberto Valverde28 Jun 2007 11:58 
Noah Gift28 Jun 2007 12:02 
Jonathan LaCour28 Jun 2007 12:02 
Mike Orr28 Jun 2007 12:31 
Jonathan LaCour28 Jun 2007 12:48 
Noah Gift28 Jun 2007 15:12 
Michael Bayer28 Jun 2007 15:38 
Michael Bayer28 Jun 2007 15:42 
Noah Gift28 Jun 2007 16:41 
rikl...@public.gmane.org28 Jun 2007 17:28 
Uwe C. Schroeder28 Jun 2007 21:03 
Mike Orr28 Jun 2007 21:55 
Noah Gift29 Jun 2007 04:49 
Mike Orr29 Jun 2007 08:32 
Noah Gift29 Jun 2007 08:35 
Subject:Re: Turbogears now based on Pylons!
From:Jonathan LaCour (jona@public.gmane.org)
Date:06/27/2007 04:01:03 PM
List:com.googlegroups.pylons-discuss

Ian Bicking wrote:

The way I see this working is something like (vaguely):

def transaction_middleware(app): def wrapper(environ, start_response): manager = TransactionManager() environ['transaction.manager'] = manager try: app_iter = app(environ, start_response) except: manager.rollback() raise else: manager.commit()

The manager is basically a container of *actual* transactions, and calling rollback or commit on it gets passed on to all the transactions in the manager.

If you don't do anything that needs a transaction (e.g., read-only), you shouldn't put your transaction in the manager.

Okay, I am mostly with you, but then you end up with a lot of boilerplate elsewhere wherever you start a transaction and throw it into the manager. I think we can address this in the TurboGears pylons template somehow and automatically start a transaction and put it into the manager on request by request basis, and provide some way to disable it for read-only requests.

There have also been discussions of allowing you to turn it off for specific HTTP methods, so you would never have a transaction for GET unless you created it yourself, but POST, DELETE, etc. would usually have transactions. This feels a touch too magical to me, since the whole point of the automatic transaction-per-request in TurboGears was to make things easy by default, and not difficult to understand.

I wouldn't have a problem if there were two separate pieces of middleware though: one for rolling back active transactions on exceptions, and another for setting up when you want those transactions to be created automatically.

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)

I'd kind of like a way of getting the "current" WSGI environment. Then one possible implementation of this config-getter is:

def get_dburi(): environ = get_environ() return environ['paste.config']['dburi']

Or it could get it out of another key, of course. And in a non-web context you have a different get_dburi() implementation. The only annoying part is actually figuring out how you get that function, and how you provide that function.

This database layer is acting as a middleman between the configuration system of the framework (Pylons, etc.) and the model itself, which may not live inside the framework. Why not just have the web framework tell the middleman how to get the dburi from the configuration, and the model can ask for the dburi from the middleman?

The way they do it in Zope, which is similar in ways to Paste's StackedObjectProxy and paste.registry, is basically something like:

dburi = getUtility('get_dburi')()

Except in Zope they use an interface instead of 'get_dburi'. But I think we should use a string.

Agreed, we should use a string.

We might want to look at PEAK's contextual stuff, as this is basically addressing the same problem. I believe Phillip recently extracted that from PEAK. (And all this config stuff is exactly the same issue as getting the current transaction manager.) Personally I'm not terribly comfortable with paste.registry and StackedObjectProxy, as I feel it pretends to be more transparent than it really is; I prefer something more explicit like getUtility().

I'll take a look at the stuff in PEAK, but it usually breaks my brain for at least two days before I finally grok it. But, to be fair, StackedObjectProxy does the same thing ;)

How should we move forward with this? Is this the type of thing that the DB-SIG cares about? Or should the discussion remain here?