On Thu, Apr 12, 2007 at 11:59:55PM -0400, Perrin Harkins wrote: > On 4/12/07, Bill Moseley <[EMAIL PROTECTED]> wrote: > > Speaking of transactions -- anyone ever asked for nested transaction > > support? > > We had a semi-long discussion about that a few weeks back, which you > can find in the archives.
Still looking, but I found your post (sorry, pre-dates my list membership) about "nested" transactions. http://sourceforge.net/mailarchive/message.php?msg_name=66887a3d0703160819x13553e99n60999254be1050f2%40mail.gmail.com > It just seems like with all of the ORMS out there and all of the > ways to use 'schema classes' from them, doing transactions in > levels (or multiple levels above) is clumsy at best. I assume you're talking about the faked multiple levels of commit that DBIx::Class provides. The simplest answer is to just stay away from all that stuff. Do the commits yourself, at the highest level. Keep it out of your O/R mapper objects. The longer answer is that since nothing but my own code ever touches transactions in my environment, I make rules that allow me to write reusable code. I keep all of it out of my O/R tools. I turn AutoCommit on. When I'm in a high-level routine and I want to make several operations transactional, I turn it off with local $dbh->{AutoCommit}. If I want to reuse that code from a context where a transaction might be active already, it nests perfectly. So, for example, in Catalyst in an end() (or something at the end) you would look for errors and then do a rollback, otherwise commit? And you look at AutoCommit to see if you need to do either of those, I assume. In general I like to get in, get the transaction done and get out because I might have a longer task that follows and don't want the transaction left open during that time. And the long-running task only happens if the transaction completes. So the nested transactions help there. Perhaps a cleaner way (other than queuing up the task for an external process) would be push a sub onto an array with the code to run after calling commit. Well, that has the problem that an exception could happen in one of the subs after the commit. Probably better to not do the subs than to do some and then rollback. I guess it's got to give some place. -- Bill Moseley [EMAIL PROTECTED] ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Rose-db-object mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rose-db-object
