On Fri, 3 Dec 1999, Tim Bunce wrote:
...
But is that _really_ what PerlFreshRestart does? I thought it destroyed
the entire perl interpreter before then recreating one from scratch?
this is the way PerlFreshRestart works at the moment. the original
implementation did destroy the interpreter
As far as I know connect_cached didn't show up untill latest versions
of DBI. And unfortunately our production services don't use those
versions.
Though there's still a disclaimer saying that the behaviour is subject
to change. Whatever. Can't I simply get rid of Apache::DBI since DBI
itself
On Sun, 5 Dec 1999, Tim Bunce wrote:
I guess I could add something like this:
DBI-default_connect_method("Apache::DBI::connect");
which Apache::DBI could call, after a "use DBI;", to get itself
plugged in.
that would be great, cos ive wanted to be able to supply my
own connect
Tim Bunce wrote:
I've always thought the "must load Apache::DBI before DBI" thing was a
bit weird anyway. Can't you just make it a flag that DBI looks at
that Apache::DBI sets?
The idea was to avoid run-time overhead by setting things up a
compile time.
I guess I could add
[EMAIL PROTECTED] (Jeffrey W. Baker) wrote:
IMHO Apache::DBI causes more problems than it solves with it's
"transparent" replacement of DBI functions. Can anyone point to an
example where a subclass of DBI would not do everything that Apache::DBI
does, except without the headaches?
Yes, here's
Ken Williams wrote:
[EMAIL PROTECTED] (Jeffrey W. Baker) wrote:
IMHO Apache::DBI causes more problems than it solves with it's
"transparent" replacement of DBI functions. Can anyone point to an
example where a subclass of DBI would not do everything that Apache::DBI
does, except without
"Jeffrey W. Baker" [EMAIL PROTECTED] writes:
Ken Williams wrote:
[EMAIL PROTECTED] (Jeffrey W. Baker) wrote:
IMHO Apache::DBI causes more problems than it solves with it's
"transparent" replacement of DBI functions. Can anyone point to an
example where a subclass of DBI would not do
Foolishness alert/Newbie approaches.
Hate that this thread died. Was following it to get some insights
into the nether regions.
I read some doc about DBI or Apache/DBI pinging or doing some kind of
trace on the other when a db connection was attempted. I thought it
made the point that
99 7:07 PM
To: Michael Smith
Cc: mod_perl mailing list; Tim Bunce; Doug MacEachern
Subject: Re: PerlFreshRestart and %INC
On Thu, Dec 02, 1999 at 06:59:26PM +, Michael Smith wrote:
I'm experiencing difficulties when using PerlFreshRestart modules that
depend on %INC. In my
-Original Message-
From: G.W. Haywood [SMTP:[EMAIL PROTECTED]]
Sent: Friday, December 03, 1999 10:04 AM
To: mod_perl Mailing List
Subject: RE: PerlFreshRestart and %INC
Hi there,
On Fri, 3 Dec 1999, Young, Geoffrey S. wrote:
maybe it has to do with the order in which
On Fri, Dec 03, 1999 at 12:00:38PM -0500, Young, Geoffrey S. wrote:
that's what I meant :)
Since %INC is a hash, and it's order unpredictable, it's possible that DBI
be re-required before Apache::DBI. But maybe something else is going on
too...
here's the code from the guide:
while
"Tim" == Tim Bunce [EMAIL PROTECTED] writes:
Tim I presumed (I've not looked) that it would reload the new interpreter
Tim in the same way that the original one was and thus would reload modules
Tim in the same order.
You can *presume* that, but I don't recall anywhere in the Perl
interpreter
[EMAIL PROTECTED] (Tim Bunce) wrote:
On Fri, Dec 03, 1999 at 12:00:38PM -0500, Young, Geoffrey S. wrote:
that's what I meant :)
Since %INC is a hash, and it's order unpredictable, it's possible that DBI
be re-required before Apache::DBI. But maybe something else is going on
too...
On Thu, Dec 02, 1999 at 06:59:26PM +, Michael Smith wrote:
I'm experiencing difficulties when using PerlFreshRestart modules that
depend on %INC. In my particular case I'm trying to use persistent
connections in DBI through Apache-DBI, and Apache/DBI is not in %INC
when PerlFreshRestart
14 matches
Mail list logo
