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 havin
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 warni
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 -> Infor
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 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: 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 missi
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 bei
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 c
On Fri, Feb 13, 2004 at 05:38:59PM -0800, Dean Arnold wrote:
> >
> > Here's what I've added to DBI 1.41:
> >
> > =item C (boolean)
> >
> > The C attribute is true if the handle object has been "executed".
> > Currently only the $dbh do() method and the $sth execute(), execute_array(),
> > and ex
On Sat, Feb 14, 2004 at 12:39:29AM +, Tim Bunce wrote:
> Here's what I've added to DBI 1.41:
>
> =item C (boolean)
>
> The C attribute is true if the handle object has been "executed".
This looks perfect, thanks!
Andrew
>
> Here's what I've added to DBI 1.41:
>
> =item C (boolean)
>
> The C 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 C attribute.
>
> When it's set on a handle
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 indi
-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 tra
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 years,
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
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.
Da
-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
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
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 th
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 know
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 t
x27;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 "Issu
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'r
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 doe
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 sa
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;
>
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,
>
27 matches
Mail list logo
