I recently learned that pyramid_tm closes the session on a transaction.commit()
I also learned that either transaction or pyramid_tm automatically commits at the end of a request I'm not comfortable with either of these behaviors, particularly the latter I've run into too many situations where my ability to continue in the application logic depends on if a transaction committed to disk or not. I'm also not too comfortable with migrating a lot of legacy code to savepoints as suggested in this discussion : https://groups.google.com/forum/#!msg/pylons-discuss/5Mj4R3YMXhI/GVFj2Du33JAJ ( btw, thanks to Eric Rasmussen for pointing that out to me ). I just read the paragraph about the transaction 'feature' in the intro ( http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/introduction.html?highlight=commit ) , and I can see how many people would enjoy this behavior - but its a bit too much magic for me. I'm porting a legacy app from Pylons to Pyramid, and there are chunks of code which use both savepoints and multiple transactions within a request.. and its going to be quite cumbersome to move the logic to this idiom. Aside from these two features, which are unarguable beneficial to a certain audience, are there any elements of transaction/pyramid_tm that I'd miss ? -- 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 pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
