62 messages in com.googlegroups.pylons-discussRe: Turbogears now based on Pylons!| From | Sent On | Attachments |
|---|---|---|
| Spider | 27 Jun 2007 06:22 | |
| rikl...@public.gmane.org | 27 Jun 2007 08:00 | |
| Jonathan LaCour | 27 Jun 2007 08:10 | |
| anderbubble | 27 Jun 2007 09:13 | |
| Mark Ramm | 27 Jun 2007 12:39 | |
| Mike Orr | 27 Jun 2007 13:45 | |
| Mark Ramm | 27 Jun 2007 14:49 | |
| Ian Bicking | 27 Jun 2007 14:56 | |
| Jonathan LaCour | 27 Jun 2007 15:26 | |
| Noah Gift | 27 Jun 2007 15:38 | |
| Ian Bicking | 27 Jun 2007 15:41 | |
| Mike Orr | 27 Jun 2007 15:45 | |
| Jonathan LaCour | 27 Jun 2007 16:01 | |
| Mike Orr | 27 Jun 2007 16:44 | |
| Mike Orr | 27 Jun 2007 16:55 | |
| Mark Ramm | 27 Jun 2007 17:06 | |
| Uwe C. Schroeder | 27 Jun 2007 17:23 | |
| Mike Orr | 27 Jun 2007 18:55 | |
| Michael Bayer | 27 Jun 2007 20:46 | |
| Michael Bayer | 27 Jun 2007 21:00 | |
| Michael Bayer | 27 Jun 2007 21:09 | |
| Michael Bayer | 27 Jun 2007 21:27 | |
| Uwe C. Schroeder | 27 Jun 2007 22:40 | |
| Mike Orr | 27 Jun 2007 23:09 | |
| Mike Orr | 27 Jun 2007 23:40 | |
| Uwe C. Schroeder | 28 Jun 2007 00:46 | |
| Wichert Akkerman | 28 Jun 2007 00:54 | |
| Mike Orr | 28 Jun 2007 01:33 | |
| Uwe C. Schroeder | 28 Jun 2007 01:50 | |
| Jonathan LaCour | 28 Jun 2007 05:55 | |
| Jonathan LaCour | 28 Jun 2007 06:58 | |
| Michael Bayer | 28 Jun 2007 07:12 | |
| Michael Bayer | 28 Jun 2007 07:20 | |
| Michael Bayer | 28 Jun 2007 07:27 | |
| Michael Bayer | 28 Jun 2007 07:34 | |
| Jonathan LaCour | 28 Jun 2007 07:53 | |
| Ian Bicking | 28 Jun 2007 08:45 | |
| Michael Bayer | 28 Jun 2007 09:31 | |
| Cliff Wells | 28 Jun 2007 09:35 | |
| Alberto Valverde | 28 Jun 2007 10:16 | |
| Alberto Valverde | 28 Jun 2007 10:29 | |
| Jonathan LaCour | 28 Jun 2007 10:32 | |
| Ian Bicking | 28 Jun 2007 10:45 | |
| Alberto Valverde | 28 Jun 2007 11:01 | |
| Alberto Valverde | 28 Jun 2007 11:15 | |
| Uwe C. Schroeder | 28 Jun 2007 11:32 | |
| Mike Orr | 28 Jun 2007 11:52 | |
| Alberto Valverde | 28 Jun 2007 11:58 | |
| Noah Gift | 28 Jun 2007 12:02 | |
| Jonathan LaCour | 28 Jun 2007 12:02 | |
| Mike Orr | 28 Jun 2007 12:31 | |
| Jonathan LaCour | 28 Jun 2007 12:48 | |
| Noah Gift | 28 Jun 2007 15:12 | |
| Michael Bayer | 28 Jun 2007 15:38 | |
| Michael Bayer | 28 Jun 2007 15:42 | |
| Noah Gift | 28 Jun 2007 16:41 | |
| rikl...@public.gmane.org | 28 Jun 2007 17:28 | |
| Uwe C. Schroeder | 28 Jun 2007 21:03 | |
| Mike Orr | 28 Jun 2007 21:55 | |
| Noah Gift | 29 Jun 2007 04:49 | |
| Mike Orr | 29 Jun 2007 08:32 | |
| Noah Gift | 29 Jun 2007 08:35 |
| Subject: | Re: Turbogears now based on Pylons!![]() |
|---|---|
| From: | Jonathan LaCour (jona...@public.gmane.org) |
| Date: | 06/28/2007 06:58:03 AM |
| List: | com.googlegroups.pylons-discuss |
Michael Bayer wrote:
just to clarify, however this works, it should be *really easy* for individual controller methods to be marked as "transactional" or not. I have written decorators like these already, in the style of:
class MyController(...): def index_page(self): .....
@transactional def post_message(self): .....
def display_message(self): .....
so id want that kind of thing to be readily available, i suppose it would communicate with the WSGI middleware on a per-request basis.
The only issue I can see with this is that having the transaction begin in the controller method itself might be too late if you have other things going on in middleware or elsewhere and something goes wrong before you even get to the controller method -- say in object dispatch, the new TG controller's "lookup" method, or even some middleware that stores sessions in a database for example.
Transactions should start at the earliest possible point, IMO, so that you can handle all of these cases.
but another thing i like, is that of the response to the request being delivered *after* the transaction commits. i have raised this issue on the pylons list before but i dont think i impressed anyone. if you render your response template, then your transaction fails, you have the potential for that response template to still be delivered with the "success!" message. anyway, might be nice for the middleware to address this if possible.
I am totally with you here, as this is the other side of the coin that I brought up above. Open transactions shouldn't be committed until the latest possible point.
I spent some dark days working on J2EE applications, and while there isn't a whole lot that is worth emulating in J2EE, the transaction handling is something that I actually liked.
also i think this is all outside of the scope of SAContext. SAContext should remain as a facade to SA-specific elements; it can accept "strategy" objects which control its internal workings, so if need be particular strategies can be delivered in order to function with the transaction manager, without changing the external view of SAContext.
Yes, I think agree here too, as long as there is a way to hook SAContext into whatever ends up getting decided in this (really long) thread. I played a bit more with SAContext after these discussions, and it is indeed very nice. Good work Mike and Mike.
-- Jonathan LaCour http://cleverdevil.org




