I find it difficult enough to jump through hoops,
much less hooks.
;)
On Wed, 2004-02-11 at 05:15, Andrew Pimlott wrote:
On Wed, Feb 11, 2004 at 09:35:59AM +, Tim Bunce wrote:
For mod_perl you can register a suitable callback.
I am using mod_perl, and that's what I mean about having to
On Mon, Feb 16, 2004 at 07:46:49PM -0600, Jay Hannah wrote:
Incidentally, you already don't get the warning during global
destruction, so it isn't that reliable.
I ran a little test against all our productions RDBMSs. As luck would have it, it
seems that it is being thrown in global
From: Tim Bunce [mailto:[EMAIL PROTECTED]
On Mon, Feb 16, 2004 at 07:46:49PM -0600, Jay Hannah wrote:
...it seems that it is being thrown in global destruction in the 2 DBD's
I use the most...
DBD::Informix - Informix 9.3:Issuing rollback() for database...
DBD::Informix -
On Tue, Feb 17, 2004 at 10:32:55AM -0600, Jay Hannah wrote:
From: Tim Bunce [mailto:[EMAIL PROTECTED]
On Mon, Feb 16, 2004 at 07:46:49PM -0600, Jay Hannah wrote:
...it seems that it is being thrown in global destruction in the 2 DBD's
I use the most...
DBD::Informix - Informix 9.3:
On Mon, Feb 16, 2004 at 07:46:49PM -0600, Jay Hannah wrote:
I shouldn't need the warning, especially when it's
wrong. Even so, it has been useful to me on many occasions in
dialogues like this:
Well, as I have thought about it more, I agree that there is some
tension between the system warning
From: Tim Bunce [mailto:[EMAIL PROTECTED]
But the Issuing rollback() warning is now only generated if AutoCommit
is turned off and Executed is true.
I'll miss the warning. It was an easy way to know I or my programmers were being
sloppy with explicit disconnects.
Enterprise wide all our
On Mon, Feb 16, 2004 at 03:46:28PM -0600, Jay Hannah wrote:
I would *love* to set another flag/whatever so DBI would bark at us
whenever $dbh's were garbage collected. Then we'd explicitly know to
slap ourselves for writing sloppy code... With the warning gone I fear
we won't know we're being
From: Andrew Pimlott [mailto:[EMAIL PROTECTED]
On Mon, Feb 16, 2004 at 03:46:28PM -0600, Jay Hannah wrote:
I would *love* to set another flag/whatever so DBI would bark at us
whenever $dbh's were garbage collected.
Can I ask exactly what you are worried about?
...
Or am I missing some
On Fri, Feb 13, 2004 at 05:38:59PM -0800, Dean Arnold wrote:
Here's what I've added to DBI 1.41:
=item CExecuted (boolean)
The CExecuted attribute is true if the handle object has been executed.
Currently only the $dbh do() method and the $sth execute(), execute_array(),
and
On Wed, Feb 11, 2004 at 09:35:59AM +, Tim Bunce wrote:
The warning as it's a significant satefy feature, however it can be
turned off, along with various other warnings, by $dbh-{Warn} = 0,
but I don't recommend that.
Tim.
p.s. The plan is to have a way for a driver to indicate if
Here's what I've added to DBI 1.41:
=item CExecuted (boolean)
The CExecuted attribute is true if the handle object has been executed.
Currently only the $dbh do() method and the $sth execute(), execute_array(),
and execute_for_fetch() methods set the CExecuted attribute.
When it's
Let's not get carried away with this thread.
When a DBI database handle is destroyed, either by the ref count
reaching 0 or by the 'global destruction' that happens when the
perl interpreter exits, the DESTROY method is called.
The DESTROY method naturally disconnects the database connection.
On Thu, 12 Feb 2004 10:55:56 +, Tim Bunce wrote:
All I'm proposing to change is to add a way for drivers to indicate
if they are in a transaction or not, and then to use that to disable
the warning.
That reminds me... I haven't used it in years, but I recall that last
time I used DBD::ODBC
On Feb 12, 2004, at 3:42 AM, Bart Lateur wrote:
On Thu, 12 Feb 2004 10:55:56 +, Tim Bunce wrote:
All I'm proposing to change is to add a way for drivers to indicate
if they are in a transaction or not, and then to use that to disable
the warning.
That reminds me... I haven't used it in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
All I'm proposing to change is to add a way for drivers to indicate
if they are in a transaction or not, and then to use that to disable
the warning.
That what I was thinking about. Since DBD::Pg already tracks whether
or not it is in a
On Tue, 10 Feb 2004 18:10:42 -0500, Andrew Pimlott wrote:
Is there any way to prevent the following from warning Issuing
rollback() for database handle being DESTROY'd without explicit
disconnect().?
use DBI;
my $dbh = DBI-connect('dbi:Pg:dbname=...', undef, undef,
{
On Wed, Feb 11, 2004 at 09:42:00AM +0100, Bart Lateur wrote:
On Tue, 10 Feb 2004 18:10:42 -0500, Andrew Pimlott wrote:
Is there any way to prevent the following from warning Issuing
rollback() for database handle being DESTROY'd without explicit
disconnect().?
use DBI;
my $dbh
On Wed, Feb 11, 2004 at 09:35:59AM +, Tim Bunce wrote:
For mod_perl you can register a suitable callback.
I am using mod_perl, and that's what I mean about having to jump through
hooks (probably not that difficult in this case) to suppress the
warning.
The warning as it's a significant
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
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
. 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
On Wed, Feb 11, 2004 at 04:24:31PM +, Tim Bunce wrote:
On Wed, Feb 11, 2004 at 08:15:12AM -0500, Andrew Pimlott wrote:
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
On Wed, Feb 11, 2004 at 11:43:49AM -0600, Jeff Holt wrote:
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
On Wed, Feb 11, 2004 at 09:41:08AM -0800, Henri Asseily wrote:
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
Actually, there at at least two things wrong with letting a dbms perform
session garbage collection.
The first is assuming a definition for session garbage collection. The
second is assuming that the dbms will always keep that definition in
spite of its evolution.
Garbage collection is defined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there any way to prevent the following from warning Issuing
rollback() for database handle being DESTROY'd without explicit
disconnect().?
...
I'm using DBI 1.40 and DBD::Pg 1.31 on Debian testing.
I played with this a bit today and am
26 matches
Mail list logo
