Re: [mp2] Using DBI instead of Apache::DBI

2003-03-13 Thread Stas Bekman
[please keep the threads on the list unless requested otherwise]

Georg Botorog wrote:
Thanks. But I still have not understood how I avoid to include
Apache::DBI in the current version of Apache (2). In mp1, there was an
explicit inclusion statement in httpd.conf, which I could leave out. I
have found nothing of the kind in mp2. Still, Apache::DBI is loaded.
Maybe I have not expressed clearly: I do not want to unimport an
included module, I simply do not want to include a special module,
Apache::DBI, at all in a certain instance of Apache.
What you are saying is that you don't load Apache::DBI, but something else 
does, right?

Install this override at the very beginning of your startup.pl and watch the 
logs to see who loads Apache::DBI.

*CORE::GLOBAL::require = sub {
warn require $_[0]\n;
CORE::require(@_)
};
This should work with 5.6.x, not sure about earlier perl versions.

-Original Message-
From:   Stas Bekman [SMTP:[EMAIL PROTECTED]
Sent:   Tuesday, March 11, 2003 11:55 PM
To: Georg Botorog
Cc: [EMAIL PROTECTED]
Subject:Re: [mp2] Using DBI instead of Apache::DBI
Georg Botorog wrote:

Hello,

In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user
connections (DBI) on the same machine required running two Apache
instances, one with Apache::DBI and the other without it.
Has anything about that changed in mod_perl2?

Moreover, how does Apache2 know it has to load Apache::DBI? There is
no PerlModule Apache::DBI statement in my httpd.conf (as it was
under mp1), neither a use Apache::DBI in startup.pl or in any

other

module. Or, to put it the other way around: how can I avoid

including

Apache::DBI (in the DBI-only instance)?

As you said Apache::DBI is either on or off and it will work just the
same 
under mp2 as it does under mp1.

However in the near future DBI is going to support pooling internally,
which 
will take the benefit of threads if available.

And I think it could be made more flexible than Apache::DBI, i.e. too
be more 
than just on or off. I think Apache::DBI can do the same. What we
really need 
is some sort of pragma where you can control Apache::DBI. e.g. let's
say that 
once you load Apache::DBI it turns the pooling on globally. But than
in your 
script you should be able to say (you can't do it just yet):

no Apache::DBI; # which calls Apache::DBI::unimport
$dbh = DBI-connect(...)
and the unimport will restore the default DBI behavior for the scope
of that 
pragma (e.g. handler) and restores to the previous behavior on the
scope exit. 
Similar to how the warnings pragma works.

It's be nice to have a generic pragma for turning any functionality on
and off 
(do we have one already?). e.g. let's call it 'override':

use override 'Apache::DBI';
# Apache::DBI overrides DBI here
no override 'Apache::DBI';
# the previous functionality is restored (e.g. back to DBI)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com




--

__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


[mp2] Using DBI instead of Apache::DBI

2003-03-11 Thread Georg Botorog
 Hello,
 
 In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user
 connections (DBI) on the same machine required running two Apache
 instances, one with Apache::DBI and the other without it.
 
 Has anything about that changed in mod_perl2?
 
 Moreover, how does Apache2 know it has to load Apache::DBI? There is
 no PerlModule Apache::DBI statement in my httpd.conf (as it was
 under mp1), neither a use Apache::DBI in startup.pl or in any other
 module. Or, to put it the other way around: how can I avoid including
 Apache::DBI (in the DBI-only instance)?
 
 Thanks
 George
 


Re: [mp2] Using DBI instead of Apache::DBI

2003-03-11 Thread Stas Bekman
Georg Botorog wrote:
Hello,

In mod_perl1, using persistent (Apache::DBI) and dedicated, per-user
connections (DBI) on the same machine required running two Apache
instances, one with Apache::DBI and the other without it.
Has anything about that changed in mod_perl2?

Moreover, how does Apache2 know it has to load Apache::DBI? There is
no PerlModule Apache::DBI statement in my httpd.conf (as it was
under mp1), neither a use Apache::DBI in startup.pl or in any other
module. Or, to put it the other way around: how can I avoid including
Apache::DBI (in the DBI-only instance)?
As you said Apache::DBI is either on or off and it will work just the same 
under mp2 as it does under mp1.

However in the near future DBI is going to support pooling internally, which 
will take the benefit of threads if available.

And I think it could be made more flexible than Apache::DBI, i.e. too be more 
than just on or off. I think Apache::DBI can do the same. What we really need 
is some sort of pragma where you can control Apache::DBI. e.g. let's say that 
once you load Apache::DBI it turns the pooling on globally. But than in your 
script you should be able to say (you can't do it just yet):

no Apache::DBI; # which calls Apache::DBI::unimport
$dbh = DBI-connect(...)
and the unimport will restore the default DBI behavior for the scope of that 
pragma (e.g. handler) and restores to the previous behavior on the scope exit. 
Similar to how the warnings pragma works.

It's be nice to have a generic pragma for turning any functionality on and off 
(do we have one already?). e.g. let's call it 'override':

use override 'Apache::DBI';
# Apache::DBI overrides DBI here
no override 'Apache::DBI';
# the previous functionality is restored (e.g. back to DBI)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com