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: | Uwe C. Schroeder (uwe-...@public.gmane.org) |
| Date: | 06/27/2007 05:23:46 PM |
| List: | com.googlegroups.pylons-discuss |
On Wednesday 27 June 2007, Mark Ramm wrote:
It sounds like Pylons and TurboGears have very different paradigms about how transactions are handled.
I can't do a side-by-side comparison, because I am not 100% clear on an example of the "right way" to handle transactions in Pylons.
But I can describe what TurboGears 1.0 does.
TG currently has an "automatic transaction per request" feature, which is very widely used.
If a request fails for any reason, at any point the exception is propigated out, and causes a transaction rollback.
We want to set up the transaction as early as possible. So that if you have validators which hit the DB (which many do) and you want that wrapped in a transaction that is done for you. And this is important because you can't do that in the controller method itself since validation happens in the decorator -- before you enter the controller method itself. And we want the transaction closed as late as possible so that if your internationalization fails or some other post controller action fails, you can rollback the transaction.
Of course the problem with the current implementation of this feature is that all kinds of pages which don't actually change anything get transaction overhead that they don't need. So we are looking for the best way to control transactions on a per controller basis.
And on that note: if you're using SA with TG, SA issues a rollback on every transaction that is not an insert or update. So if you're having a stored procedure (which you trigger with "select * from stored_proc()" and that stored procedure actually does updates or inserts, you're going to lose changes - simply because SA issues a rollback on Select statements. Quick fix for this is to modify SA to just issue a commit on every statement, so the TG transaction can roll back or commit without being affected. IMHO issuing a commit on a select shouldn't be more overhead than issuing a rollback - because the db should know what to do (in this case nothing)
Maybe something to think about too, because I can't be the only one making heavy use of stored procedures (which are far more efficient than controller/model side code)
Uwe
-- Open Source Solutions 4U, LLC 1618 Kelly St Phone: +1 707 568 3056 Santa Rosa, CA 95401 Cell: +1 650 302 2405 United States Fax: +1 707 568 6416




