What does a DBIx::* module have to do in order to correctly call Apache::DBI's no-op version of disconnect() when running under mod_perl with Apache::DBI?
Below is an example that illustrates a bug I found when using a particular
DBIx:: module.
---
package MyTest;
use strict;
use Apache::DBI;
use DBIx::ContextualFetch;
sub handler
{
my($r) = shift;
my $dbh = DBI->connect('dbi:...', 'myuser', 'mypass',
{ RootClass => 'DBIx::ContextualFetch' });
$r->send_http_header('text/plain');
$dbh->do('...any valid sql...') ?
print 'OK' : print 'Failed';
$dbh->disconnect; # This calls the wrong disconnect()!
return 200;
}
1;
---
Run it under httpd -X to further isolate the problem and you'll see that the
first request works, but all subsequent requests fail. This happens because
the disconnect() call actually calls the "real" disconnect method instead of
the Apache::DBI implementation, which is a no-op. On the next request,
Apache::DBI happily provides what is now a disconnected $dbh. Any attempt
to use that $dbh fails, obviously.
If you enable Apache::DBI's debugging output ($Apache::DBI::DEBUG = 1),
you'll see that the correct connect() method is called. That is, only one
connection is made and then re-used.
So, getting back to my original question, who is at fault here? Is this an
Apache::DBI bug, a DBIx::ContextualFetch bug, or something else?
One easy "fix" is to add a disconnect() method to DBIx::ContextualFetch that
detects when Apache::DBI is in use. Example:
sub DBIx::ContextualFetch::disconnect
{
if($ENV{'MOD_PERL'} && $Apache::DBI::VERSION)
{
# Do nothing when Apache::DBI is in use
return 1;
}
shift->SUPER::disconnect(@_);
}
But isn't Apache::DBI supposed to be "transparent" and do all this stuff for
me? Or are all bets off when using a DBIx module? If so, what is a DBIx
author supposed to do to be a "good Apache::DBI
Re: [clug-talk] YUM chossing repositories is vital (was: my experience w
clug-talk
Chronological
-->
Thread
-->
Re: [clug-talk] YUM chossing repositories is vital (was: my experience with Fedora Core 2)
- From: Niels Voll
- Subject: Re: [clug-talk] YUM chossing repositories is vital (was: my experience with Fedora Core 2)
- Date: Tue, 25 May 2004 22:19:09 -0700
Apache::DBI and DBIx::*
John Siracusa
Fri, 13 Aug 2004 12:26:11 -0700
In my experience yum is really slow with the default Fedora server even
on very fast hardware. When using a fast (using the world loosely)
server, it is a hugely more positive experience. I've had very good
success with kernel.org's yum mirror for RH9 and FC1. Changing servers
needs to be done in the yum config file in /etc A bit ugly to still
have to do it that way, but a must to start having a pleasant experience
with yum. (disclaimer: I've only used yum on broadband, never on
dial-up, and I've only used it with lots of RAM and >2.4GHz CPU).
By the way, yum has excellent repositories for legacy RH distro's; I'm aware of RH8 and RH9, not sure, but maybe RH7 is even supported.
And there are additional yum capable repositories kicking around for FC (google for it); these allow easy installation and updates for packages beyond the "Core" of Fedora.
By the way, yum has excellent repositories for legacy RH distro's; I'm aware of RH8 and RH9, not sure, but maybe RH7 is even supported.
And there are additional yum capable repositories kicking around for FC (google for it); these allow easy installation and updates for packages beyond the "Core" of Fedora.
...Niels
Jesse Kline wrote:
Actually Yum really is slow as a mother... I used apt, up2date and Yum on the same old machine, and what apt would do in 30 seconds, Yum would take hours to do (seriously). I think I left it to d/l headers overnight, and then when it was finnished all that it gave me an error and didn't end up doing anything.
Jesse<Re: [pgadmin-hackers] pgAdmin 1.1.0 pgadmin-hackers
<-- Chronological --> <-- Thread --> Re: [pgadmin-hackers] pgAdmin 1.1.0
- From: Jean-Michel POURE
- Subject: Re: [pgadmin-hackers] pgAdmin 1.1.0
- Date: Fri, 14 Nov 2003 09:00:19 -0800
Apache::DBI and DBIx::*
John Siracusa
Fri, 13 Aug 2004 12:26:11 -0700Le Vendredi 14 Novembre 2003 16:28, Lafriks a �crit : > When it will be released? :) I just want to know how much time I have > left to do Latvian translation :) Dear Lafriks, I have no idea when pgAdmin3 1.1 will be released. Nearly everyday, we try to publish binary snapshots from CVS. Whenever you deliver, your translations are publised in Snapshots immediately. The snapshots are available from: http://www.pgadmin.org/pgadmin3/download.php#snapshots Do not hesitate to deliver a first 'raw' Latvian translation. It will give you some time to correct the text and make an update later on. Best regards, Jean-Michel Pour� ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
Reply via email to
