On Wed, Aug 10, 2005 at 11:07:10AM -0500, Jacob Kaplan-Moss wrote: > The problem with this approach -- which was our first idea, by the > way -- is that it doesn't handle multiple simultaneous transactions. > Now, I'm not sure I can coherently articulate an example where this > would be useful, but I know I've seen code in the past that required > this feature.
Okay. I think you need to have multiple connections to do that - is there support for that in the existing code? (Actually I'm sure you need separate connections with dbAPI 2 - rollback and commit are connection methods, not cursor methods. psycopg has (or used to have?) some very non-standard capabilities in that direction.) But yeah, if multiple concurrent transactions in one app are necessary I guess you have to pass that extra state around. > As an aside, this is *exactly* where Python needs those anonymous > blocks things that have been thrown around; something like:: > > with db.transaction(): > # code here > > would be awesome. Isn't this a throwback to the single transaction limitation? Or do I misunderstand PEP 343 (quite possible, that). -- Slashdot: confirming Sturgeon's Law, 24x7
