It's an excellent idea for the DBI to fake certain things when it makes sense. But transaction control is not one of them. Transaction control is appropriately handled only by an application. In other words, only an application knows when it should or should not commit or rollback.
Additionally, an application is irresponsible if it doesn't explicitly disconnect from a session/service. For feature-rich dbms's, there are well documented cases of outages caused by irresponsible applications. Of course, you can say "it's just a simple one-off piece of code that won't run more than once". And I'll say, "you need to establish good coding practices, not bad ones". -----Original Message----- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 10:25 To: [EMAIL PROTECTED] Subject: Re: getting rid of the "Issuing rollback()" warning On Wed, Feb 11, 2004 at 08:15:12AM -0500, Andrew Pimlott wrote: > > > p.s. The plan is to have a way for a driver to indicate if it's in > > a transaction and, for drivers that can, use that to skip the > > warning. > > Ok, so you'd like to issue the warning in the dangerous case only, but > DBI doesn't have the necessary information. That seems like a rather > conspicuous flaw in the design, but I'm glad there's a plan to fix it! Calling it a "conspicuous flaw in the design" glosses over the fact that many drivers and database API's can't tell if they are or not. (And it can't be very conspicuious as the warning has been there for many years and few people have commented on it.) I generally only add something to the DBI when the DBI can 'fake it' for drivers that can't do it themselves. In this case the DBI will count execute()/do() calls and reset the counter on commit()/rollback(). Then the counter can be used to control the warning for drivers that can't tell if they're in a transaction or not. Tinm.
