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 PerlFreshResta
, December 02, 1999 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 PerlFr
Hi there,
On Fri, 3 Dec 1999, Young, Geoffrey S. wrote:
> maybe it has to do with the order in which stuff is held in %INC - that is,
> Apache::DBI needs to be loaded before DBI, but PerlFreshRestart may require
> them in the improper order because of the hash order?
Is there a `hash order'?
Ha
quire $k;
}
--Geoff
> -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, Geoffr
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:
>
>
> "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
int
Message-
> From: Tim Bunce [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, December 03, 1999 12:30 PM
> To: Young, Geoffrey S.
> Cc: 'G.W. Haywood'; mod_perl Mailing List
> Subject: Re: PerlFreshRestart and %INC
>
> On Fri, Dec 03, 1999 at 12:00:38PM -0500, Youn
[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 3 Dec 1999, Randal L. Schwartz wrote:
> I've always thought the "must load Apache::DBI before DBI" thing was a
> bit weird anyway.
With you all the way on that one.
> Can't you just make it a flag that DBI looks at that Apache::DBI sets?
Yeulk.
I'd like to see a lot more attention paid to
Hi there,
On Fri, 3 Dec 1999, Young, Geoffrey S. wrote:
> here's the code from the guide:
>
> while (my($k,$v) = each %INC) {
> delete $INC{$k};
> require $k;
> }
I don't know what you'd do about that then.
Whatever you do, you're bound to break _something_.
73
Ged.
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 Apache/DBI
On Fri, Dec 03, 1999 at 09:41:03AM -0800, Randal L. Schwartz wrote:
> > "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 sa
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 conne
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 ad
[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
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
"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 D
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 offe
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
On Thu, 2 Dec 1999, 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 causes DBI to be l
20 matches
Mail list logo
