Michael Bayer wrote: > On Jun 27, 6:42 pm, Ian Bicking <[EMAIL PROTECTED]> 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. > > this is fine. we're *really* starting to imitate J2EE in some ways. > but its not a bad thing.
At least someone else thought it was a good idea too ;). It's also all very similar to Zope. >> If you don't do anything that needs a transaction (e.g., read-only), you >> shouldn't put your transaction in the manager. > > 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. 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. > 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. 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. > 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. 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. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
