Re: Apache::DBI
It looks like your PostgreSQL installation is trying to do IDENT
authentication, instead of MD5. So, it's checking the user your script is
running as, and trusting that since you managed to log on with your
username/password already, it'll trust you to log into the database.
While this isn't strictly an Apache problem, but rather a database problem,
here's what's probably the matter. In your /var/lib/pgsql/data/pg_hba.conf
file, you probably have the default:
local all all trust
I would suggest changing this to something like:
local all all md5
or make it IP based:
host allall1.2.3.4255.255.255.255 md5
you get the idea. That way, it'll obey the username/password that you supply.
On Thursday 28 August 2003 04:28 pm, wrote:
Hello, every body
I can run the following subroutine in DBI, but Apache::DBI...
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,3dsadasz);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row = $sth-fetch){
my($clave, $nombre) = @$row;
print clave = $clave, denominacion = $nombre\n;
}
$dbh-disconnect;
}
and I have this log...
[Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory:
mod_mime_magic: can't read magic file /etc/apache-perl/share/magic
[Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
mod_perl/1.26 configured -- resuming normal operations
[Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default:
sysvsem) [Thu Aug 28 12:37:03 2003] null: DBI-connect(dbname=test) failed:
FATAL 1: IDENT authentication failed for user canis at
/var/lib/perl/JCVA/Conexion.pm line 11
[Thu Aug 28 12:37:03 2003] [error] Can't call method prepare on an
undefined value at /var/lib/perl/JCVA/Conexion.pm line 13.
Somedody knows if the user must be registered in some configuration file?
--
/* Michael A. Nachbaur [EMAIL PROTECTED]
* http://nachbaur.com/pgpkey.asc
*/
Another world, another day, another dawn.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI not really loading
I've set Apache::DBI::DEBUG to 2, and I'm not seeing _any_ messages (from it) in the error log. Apache::Status lists Apache DBI, but lists no database connections. A long time ago, one problem used to be that if your connect to Postgres was idle for too long ( 8 hours ) the connection would timeout and give you these kinds of errors. One solution was to make sure that you hit a web page that has such a connection periodically, 1) Wasn't this problem corrected by using the ping() method? 2) I'm hoping for a clue why Apache::DBI is there but not giving any messages or having any connections in Apache::Status 3) Avoiding timeout doesn't help when the network hiccups and drops existing connections (I don't admin the network, can't change that) This may not be related to your current problem, so YMMV. Doesn't appear helpful, but I appreciate some response :) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI
On Mon, 18 Aug 2003, wrote: Date: Mon, 18 Aug 2003 16:57:13 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Apache::DBI What's the diference between DBI and Apache::DBI? Have you bothered to read the docs at all? http://search.cpan.org/author/TIMB/DBI-1.37/DBI.pm http://search.cpan.org/author/ABH/Apache-DBI-0.92/DBI.pm ky -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI and temporary tables
On Tue, 2003-07-22 at 17:15, Michael A Nachbaur wrote: If I do a $dbh-disconnect, I know it will be ignored by Apache::DBI, but is it smart enough to pass something back to the database server telling it that it can purge temporary data? No. If you come up with a way to do that, you can add it as a cleanup handler. - Perrin
Re: Apache::DBI and temporary tables
On Tue, 22 Jul 2003 14:15:41 -0700 Michael A Nachbaur [EMAIL PROTECTED] wrote: Hello all, I know from a DBI perspective, when using PostgreSQL, if I create a temporary database table it will automatically go *poof* and be deleted when the database connection is closed (or when the transaction is finished...I can't remember which). Anyway, what will happen if code that takes advantage of this is used in an Apache Registry script? If I do a $dbh-disconnect, I know it will be ignored by Apache::DBI, but is it smart enough to pass something back to the database server telling it that it can purge temporary data? While I'm not 100% sure, I would seriously doubt it since Apache::DBI doesn't call the corresponding DBD's disconnect method. I would do one of the following: 1) Explicitly clean up your temp table. 2) See if you can stop using Apache::DBI. I found on several sites that Apache::DBI didn't effect performance as much as I would have imagined with PostgreSQL and was fine to run without it. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
Re: Apache::DBI on mp2
On Thu, 6 Mar 2003, Stas Bekman wrote: re: rollback, the DBD drivers will perform the normal disconnect(), but without doing the physical disconnect, and normal DESTROY, without destroying the datastructures which maintain the physical connection, so there shouldn't be much to change for this feature. If the physical connection is still there, would the database server do a rollback? - ask ps. yes, your DBI::Pool work is great. Thank you. :-) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Apache::DBI on mp2
Ask Bjoern Hansen wrote: On Thu, 6 Mar 2003, Stas Bekman wrote: re: rollback, the DBD drivers will perform the normal disconnect(), but without doing the physical disconnect, and normal DESTROY, without destroying the datastructures which maintain the physical connection, so there shouldn't be much to change for this feature. If the physical connection is still there, would the database server do a rollback? If earlier the rollback worked correctly with $dbh ||= connect();, this will work the same, since it performs the same operation, but rips off only parts of $dbh, because of the constraints of sharing Perl datastructures and underlying C structs. ps. yes, your DBI::Pool work is great. Thank you. :-) My pleasure. Thanks for the kind words. It's quite challenging, though you stop getting excited about segfaults and ddd (gdb frontend) is nowadays my best friend ;) __ 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
Re: Apache::DBI on mp2
On Fri, 7 Mar 2003, Stas Bekman wrote: If the physical connection is still there, would the database server do a rollback? If earlier the rollback worked correctly with $dbh ||= connect();, this will work the same, since it performs the same operation, but rips off only parts of $dbh, because of the constraints of sharing Perl datastructures and underlying C structs. Apache::DBI explicitly calls $dbh-rollback (when things are configured so it makes sense). Or maybe I am completely misunderstanding you. ps. yes, your DBI::Pool work is great. Thank you. :-) My pleasure. Thanks for the kind words. It's quite challenging, though you stop getting excited about segfaults and ddd (gdb frontend) is nowadays my best friend ;) :-) You are quite the masochist if you ever got excited about segfaults. I only recall segfaults making me slam my head into the wall to conceal the pain. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Apache::DBI on mp2
Ask Bjoern Hansen wrote: On Fri, 7 Mar 2003, Stas Bekman wrote: If the physical connection is still there, would the database server do a rollback? If earlier the rollback worked correctly with $dbh ||= connect();, this will work the same, since it performs the same operation, but rips off only parts of $dbh, because of the constraints of sharing Perl datastructures and underlying C structs. Apache::DBI explicitly calls $dbh-rollback (when things are configured so it makes sense). Or maybe I am completely misunderstanding you. All I was saying is, that whatever worked for Apache::DBI will work for internal pooling. ps. yes, your DBI::Pool work is great. Thank you. :-) My pleasure. Thanks for the kind words. It's quite challenging, though you stop getting excited about segfaults and ddd (gdb frontend) is nowadays my best friend ;) :-) You are quite the masochist if you ever got excited about segfaults. I only recall segfaults making me slam my head into the wall to conceal the pain. I meant in the way that when something is repeated too many times it's not the same anymore ;) so s/excited/annoyed/ will do ;) __ 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
Re: Apache::DBI on mp2
On Wed, 5 Mar 2003, Stas Bekman wrote: Great. I've already committed that patch. Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or to use the mp2 API if mp2 is used. That seems like it'll be an easy solution. I thought loading Apache::compat would have global side effects though? (i.e. for people trying to make their system run without Apache::compat). - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Apache::DBI on mp2
Ask Bjoern Hansen wrote: On Wed, 5 Mar 2003, Stas Bekman wrote: Great. I've already committed that patch. Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or to use the mp2 API if mp2 is used. That seems like it'll be an easy solution. I thought loading Apache::compat would have global side effects though? (i.e. for people trying to make their system run without Apache::compat). Please scratch that idea than ;) Though it can be documented, including the Apache::compat warning ;) And instead simply add the code to handle it differently if $mod_perl::VERSION = 1.99, using the 2.0 API. __ 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
Re: Apache::DBI on mp2
Stas Bekman wrote: FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list and having already a sort-of-working prototype. So hopefully there will be no need for Apache::DBI in the near future, as DBI will be able to handle pooling internally. However it may take some time, as the drivers will have to adjust to support the new functionality. You can see the thread here: http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 Some working examples are attached to this message: http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html This is totally cool, Stas! Nice work. I look forward to answering yes when people ask if mod_perl has database connections pooling. By the way, to completely get rid of Apache::DBI this would need to cover the safety functionality in there as well, i.e. the pinging and the part where it rolls back any pending transactions when a a handle is returned to the pool. - Perrin
Re: Apache::DBI on mp2
Perrin Harkins wrote: Stas Bekman wrote: FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list and having already a sort-of-working prototype. So hopefully there will be no need for Apache::DBI in the near future, as DBI will be able to handle pooling internally. However it may take some time, as the drivers will have to adjust to support the new functionality. You can see the thread here: http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 Some working examples are attached to this message: http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html This is totally cool, Stas! Nice work. I look forward to answering yes when people ask if mod_perl has database connections pooling. ;) actually it's going to be: if perl has database connections pooling, which will include mod_perl by definition. Also, the pooling mechanism should work transparently w/ and w/o threads on the user level. By the way, to completely get rid of Apache::DBI this would need to cover the safety functionality in there as well, i.e. the pinging and the part where it rolls back any pending transactions when a a handle is returned to the pool. Certainly. Quite a few features are missing. The first step was (is) to make the dbh shared between threads (which is far from trivial). The rest should be just a matter of coding. re: rollback, the DBD drivers will perform the normal disconnect(), but without doing the physical disconnect, and normal DESTROY, without destroying the datastructures which maintain the physical connection, so there shouldn't be much to change for this feature. Only the ping() is needed to be added to connect(). __ 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
Re: Apache::DBI on mp2
On Today at 11:16am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB FWIW, we are discussing the internal DBI pooling mechanism at the SB dbi-dev list and having already a sort-of-working prototype. So SB hopefully there will be no need for Apache::DBI in the near future, as SB DBI will be able to handle pooling internally. However it may take SB some time, as the drivers will have to adjust to support the new SB functionality. SB SB You can see the thread here: SB http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 SB SB Some working examples are attached to this message: SB http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html SB Stas, Thanks for your response. I will try and keep up with the developments in the above-mentioned threads. However, for now, I'll focus on your alternate solution as mentioned below. If I find some free time (what are the chances?) I may also give DBI::Pool a try under mp2. SB [..snip..] SB SB If you apply the following patch (will commit it soon) against the modperl-2.0 SB source, you will be able to use connect_on_init unmodified, assuming that SB Apache::compat was loaded before Apache::DBI. Let me know whether it works for SB you. SB I'm happy to report that the patch to lib/Apache/compat.pm works. I did not even have to use CVS versions of any of the packages. Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0 I simply patched: /usr/lib/perl5/vendor_perl/5.8.0/i686-linux/Apache2/Apache/compat.pm with your patch and connect_on_init works unmodified. And as mentioned in your email, I do have Apache::compat loaded before Apache::DBI. Cheers, -- Haroon Rafique [EMAIL PROTECTED]
Re: Apache::DBI on mp2
Haroon Rafique wrote: On Today at 11:16am, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB FWIW, we are discussing the internal DBI pooling mechanism at the SB dbi-dev list and having already a sort-of-working prototype. So SB hopefully there will be no need for Apache::DBI in the near future, as SB DBI will be able to handle pooling internally. However it may take SB some time, as the drivers will have to adjust to support the new SB functionality. SB SB You can see the thread here: SB http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118 SB SB Some working examples are attached to this message: SB http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html SB Stas, Thanks for your response. I will try and keep up with the developments in the above-mentioned threads. However, for now, I'll focus on your alternate solution as mentioned below. If I find some free time (what are the chances?) I may also give DBI::Pool a try under mp2. I've already tried it and it works ;) However DBI::Pool won't have a life on its own and will be integrated into DBI itself and its DBD drivers. SB [..snip..] SB SB If you apply the following patch (will commit it soon) against the modperl-2.0 SB source, you will be able to use connect_on_init unmodified, assuming that SB Apache::compat was loaded before Apache::DBI. Let me know whether it works for SB you. SB I'm happy to report that the patch to lib/Apache/compat.pm works. I did not even have to use CVS versions of any of the packages. Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0 I simply patched: /usr/lib/perl5/vendor_perl/5.8.0/i686-linux/Apache2/Apache/compat.pm with your patch and connect_on_init works unmodified. And as mentioned in your email, I do have Apache::compat loaded before Apache::DBI. Great. I've already committed that patch. Perhaps Ask could load 'Apache::compat' inside Apache::DBI if mp2 is used. Or to use the mp2 API if mp2 is used. __ 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
Re: Apache::DBI on mp2
FWIW, we are discussing the internal DBI pooling mechanism at the dbi-dev list
and having already a sort-of-working prototype. So hopefully there will be no
need for Apache::DBI in the near future, as DBI will be able to handle pooling
internally. However it may take some time, as the drivers will have to adjust
to support the new functionality.
You can see the thread here:
http://archive.develooper.com/[EMAIL PROTECTED]/index.html#02118
Some working examples are attached to this message:
http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html
Haroon Rafique wrote:
My setup is as follows:
Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_08 Perl/v5.8.0
mod_perl was built from CVS.
I was interested in getting Apache::DBI to run under mp2. I did read
Ask's message at
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
which leads me to my question. What would it take to get connect_on_init
to run under mp2?
With the following patch I was able to get connect_on_init to work under
mp2. Remember that my objective was to JUST get it to run. This is NOT
release quality code. I'm happy to report that it works for me, so far.
Anyone else who is running mp2 (no compat mode) willing to give it a try?
Of course, then the gurus can come in and clean up the code so that it
works under either mp1 or mp2.
If you apply the following patch (will commit it soon) against the modperl-2.0
source, you will be able to use connect_on_init unmodified, assuming that
Apache::compat was loaded before Apache::DBI. Let me know whether it works for
you.
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.81
diff -u -r1.81 compat.pm
--- lib/Apache/compat.pm19 Feb 2003 23:55:23 - 1.81
+++ lib/Apache/compat.pm3 Mar 2003 23:49:19 -
@@ -125,6 +125,16 @@
die $err if $err;
}
+sub push_handlers {
+shift;
+Apache-server-push_handlers(@_);
+}
+
+sub set_handlers {
+shift;
+Apache-server-set_handlers(@_);
+}
+
package Apache::Constants;
use Apache::Const ();
__
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
Re: Apache::DBI and mod_perl 2
[EMAIL PROTECTED] wrote: Any plans to make Apache::FakeRequest work well enough to make this possible? [EMAIL PROTECTED] wrote: As for mod_perl 1.0, I'm not sure, but if you can make it useful that would be cool. A while back Andrew Ho posted his script, apr, that is similar to Apache::FakeRequest: http://marc.theaimsgroup.com/?l=apache-modperlm=98719810927157w=2 I've attached a slightly updated version called runtsp. Although it's called runtsp, it should handle Apache::Registry scripts just fine. (Tellme::Apache::TSP is our templating module a la Apache::ASP.) - Kyle runtsp Description: Binary data
RE: Apache::DBI and mod_perl 2
Also remember, that you can't test modules that require mod_perl to run from the command line. You'd have the same result with mod_perl 1.0 Thanks, I didn't know that at all as I test all my modules that way and have never had a problem.. Of course most are not mod_perl specific. -Chris
Re: Apache::DBI and mod_perl 2
[EMAIL PROTECTED] wrote: Any plans to make Apache::FakeRequest work well enough to make this possible? There are plans. Here is an entry from modperl-2.0/todo/api.txt: Apache::FakeRequest: since APR can be used outside of httpd, and we can alloc request_rec and similar structures, it should be possible to bootstrap an inside-httpd interface and outside-httpd interface. its not really worthwhile looking at until APR actually installs its *.so or *.a libraries somewhere apxs can find them. and, there's a bunch of util functions (e.g. URI stuff) that is supposed to move from httpd into apr-util. As for mod_perl 1.0, I'm not sure, but if you can make it useful that would be cool. __ 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
Re: Apache::DBI and mod_perl 2
Chris Faust wrote: Hey Helmut, Yes, I'm sure its Apache::DBI - when I try to check for it directly via perl -MModule::Name, I get the error.. Where is a copy paste from the command line. [chrisf@web1 chrisf]$ perl -MApache::DBI -e 0 Can't locate Apache/Constants.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 [...] Also remember, that you can't test modules that require mod_perl to run from the command line. You'd have the same result with mod_perl 1.0 __ 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
Re: Apache::DBI and mod_perl 2
Hi Chris, are you shure that is is the Apache::DBI, that needs the Apache::Constants or is it another module? For me Apache::DBI loads without problems (2.044/1.9908/5.8) even without the use compat(); compatibility layer. Helmut --On Friday, February 14, 2003 09:00:31 -0500 Chris Faust [EMAIL PROTECTED] wrote: Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I can't find
anything in any of the docs and even goggle groups only had one message and
the solution didn't relate.
Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08
and if I try to use Apache::DBI I receive the error of:
Can't locate Apache/Constants.pm in @INC
I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new
classes (Apache::Const,APR::Const,Modperl::Const).
But what do I do to get Apache::DBI to work?
Am I missing something really simple here (I hope)?
Thanks
-Chris
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
Hey Helmut, Yes, I'm sure its Apache::DBI - when I try to check for it directly via perl -MModule::Name, I get the error.. Where is a copy paste from the command line. [chrisf@web1 chrisf]$ perl -MApache::DBI -e 0 Can't locate Apache/Constants.pm in @INC (@INC contains: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 6. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache.pm line 6. Compilation failed in require at /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 3. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.8.0/Apache/DBI.pm line 3. Compilation failed in require. BEGIN failed--compilation aborted. [chrisf@web1 chrisf]$ I get pretty much the same thing if I try to put it into my statup.pl, scripts or httpd.conf. Thanks -Chris -Original Message- From: Dr. Helmut Zeilinger [mailto:[EMAIL PROTECTED]] Sent: Friday, February 14, 2003 9:26 AM To: Chris Faust; Modperl Subject: Re: Apache::DBI and mod_perl 2 Hi Chris, are you shure that is is the Apache::DBI, that needs the Apache::Constants or is it another module? For me Apache::DBI loads without problems (2.044/1.9908/5.8) even without the use compat(); compatibility layer. Helmut --On Friday, February 14, 2003 09:00:31 -0500 Chris Faust [EMAIL PROTECTED] wrote: Hi, My problem seems like one that would be well documented, but I can't find anything in any of the docs and even goggle groups only had one message and the solution didn't relate. Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with Mod_Perl 1.99.08 and if I try to use Apache::DBI I receive the error of: Can't locate Apache/Constants.pm in @INC I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new classes (Apache::Const,APR::Const,Modperl::Const). But what do I do to get Apache::DBI to work? Am I missing something really simple here (I hope)? Thanks -Chris
RE: Apache::DBI and mod_perl 2
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
Thanks
-Chris
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 10:22 AM
To: Chris Faust
Cc: Modperl
Subject: Re: Apache::DBI and mod_perl 2
Do you have the latest Apache::DBI ? Ask made a new one a couple of weeks
ago to run with mp2.
On Fri, 14 Feb 2003, Chris Faust wrote:
Hi,
My problem seems like one that would be well documented, but I
can't find
anything in any of the docs and even goggle groups only had
one message and
the solution didn't relate.
Anyway, I've updated to RedHat 8.0 and Apache 2.0.44 with
Mod_Perl 1.99.08
and if I try to use Apache::DBI I receive the error of:
Can't locate Apache/Constants.pm in @INC
I've learned in mod_perl 2 that Apache::Constants was replaced by 3 new
classes (Apache::Const,APR::Const,Modperl::Const).
But what do I do to get Apache::DBI to work?
Am I missing something really simple here (I hope)?
Thanks
-Chris
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message you want is
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
- nick
Nick Tonkin {|8^)
RE: Apache::DBI and mod_perl 2
Awesome!! That must be my problem..
I searched everyplace else, but totally forgot searching the list..
Sorry about that.
Thanks Again!!
-Chris
-Original Message-
From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 10:46 AM
To: Chris Faust
Cc: Modperl
Subject: RE: Apache::DBI and mod_perl 2
On Fri, 14 Feb 2003, Chris Faust wrote:
Maybe that is the problem?
I'm using 0.89 which is the newest from CPAN and that shows Jun 18..
Is there a later version available?
You can always search the archives of this list at
http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
The message you want is
http://marc.theaimsgroup.com/?l=apache-modperlm=104225578207460w=2
- nick
Nick Tonkin {|8^)
Re: Apache::DBI
On Mon, 6 Jan 2003, Paul Simon wrote: --- Randy Kobes [EMAIL PROTECTED] wrote: Are you using the latest versions of DBI and DBD::ODBC? If not, does an upgrade help? Those modules are - whatever was bundled with your first, warmly supplied :), Perl 5.8 + apache2 package on theoryx5. Possibly, DBI = 1.30 and DBD::ODBC = 0.43 If this is still a problem, you might try an upgrade - both DBI and DBD::ODBC are at newer versions now. We have ppm packages (for ActivePerl 8xx builds) of them at http://theoryx5.uwinnipeg.ca/ppms/ -- best regards, randy
Re: Apache::DBI
Paul Simon wrote: I wasn't sure if Apache::DBI was screwing with ORACLE, especially with persistent connections... The Apache::DBI code is really short and easy to read. Basically, it just doesn't close connections when you call disconnect. It also does automatic rollbacks at the end of each request to make sure nothing is left in a bad state, and it pings the db connection each time you ask for one to make sure it's still alive. There's nothing in there that should interfere with the normal workings of DBI. - Perrin
RE: Apache::DBI
Hi Paul -
It is my understanding that Apache::DBI is not yet
implemented for Apache2/mod_perl2. I had to comment
out my references to it in the startup script and/or
the configuration file.
Take a look at:
http://beaucox.com/mason/mason-with-apmp2-mini-HOWTO.htm
for further info.
Aloha = Beau.
-Original Message-
From: Paul Simon [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 02, 2003 3:00 AM
To: [EMAIL PROTECTED]
Subject: Apache::DBI
Hi all
I have a feeling this may be [OT], take it to the DBI
list... But I'm hoping to eliminate as much as
possible any suspicion that Apache::DBI/mod_perl is
causing my headache. I'm trying to push this platform
at work ;) If anyone can shed some light on this then
I'd be very appreciative, of course.
I have what's becoming a reoccuring problem with an
app running under:
Apache/2.0.42 (Win32) mod_perl/1.99_08-dev Perl/v5.8.0
I'm using Apache::compat and Apache::DBI for
persistent database connections.
Here are the configurations in the httpd.conf file:
#
LoadFile C:/Perl/bin/perl58.dll
LoadModule perl_module modules/mod_perl.so
PerlOptions +Parent
PerlInterpStart 10
PerlInterpMax 50
PerlInterpMaxSpare 25
PerlRequire C:/Apache2pl/conf/startup.pl
#-
The startup.pl looks like this:
#-
#!C:/Perl/bin/Perl.exe
use Apache2();
use lib('/Apache2pl/lib/perl/Apache');
use ModPerl::Registry();
use Apache::compat;
use Apache::DBI;
use DBI;
use DBD::ODBC;
use HTML::Template;
use CGI::Lite;
#$Apache::DBI::DEBUG = 2;
use Standard3;
1;
#-
For completeness sake, here's the connection string:
my $DBH = DBI-connect(DBI:ODBC:$db, $user, $pass,
{ RaiseError = 1, PrintError = 1, AutoCommit = 1 })
or print( Unable to connect to Database:
$DBI::errstr\n ) ;
Finally, the error message I'm getting is:
DBI-connect(pdb9) failed:
[Oracle][ODBC][Ora]ORA-12535: TNS:operation timed out
(SQL-S1000)(DBD: db_login/SQLConnect err=-1) at
/Apache2/lib/perl/Apache/Standard3.pm line 29
This problem goes away if the ORacle server(on it's
own hardware running windows 2000 pro) is restarted.
The last time this happened the box Oracle resides on
needed a cold reboot! So far, I haven't had to restart
apache.
Could Apache::DBI or mod_perl2 cause this behavior?
Paul
Re: Apache::DBI
On Thu, 2 Jan 2003, Paul Simon wrote:
Hi all
I have a feeling this may be [OT], take it to the DBI
list... But I'm hoping to eliminate as much as
possible any suspicion that Apache::DBI/mod_perl is
causing my headache. I'm trying to push this platform
at work ;) If anyone can shed some light on this then
I'd be very appreciative, of course.
I have what's becoming a reoccuring problem with an
app running under:
Apache/2.0.42 (Win32) mod_perl/1.99_08-dev Perl/v5.8.0
I'm using Apache::compat and Apache::DBI for
persistent database connections.
[ ... ]
For completeness sake, here's the connection string:
my $DBH = DBI-connect(DBI:ODBC:$db, $user, $pass,
{ RaiseError = 1, PrintError = 1, AutoCommit = 1 })
or print( Unable to connect to Database:
$DBI::errstr\n ) ;
Finally, the error message I'm getting is:
DBI-connect(pdb9) failed:
[Oracle][ODBC][Ora]ORA-12535: TNS:operation timed out
(SQL-S1000)(DBD: db_login/SQLConnect err=-1) at
/Apache2/lib/perl/Apache/Standard3.pm line 29
This problem goes away if the ORacle server(on it's
own hardware running windows 2000 pro) is restarted.
The last time this happened the box Oracle resides on
needed a cold reboot! So far, I haven't had to restart
apache.
Could Apache::DBI or mod_perl2 cause this behavior?
When you say the problem goes away, does this mean that
things work fine after the restart of the Oracle server?
Or do you periodically have to do this restart?
Are you using the latest versions of DBI and DBD::ODBC?
If not, does an upgrade help?
--
best regards,
randy kobes
Re: Apache::DBI seg fault
On Wed, 20 Nov 2002, Beau E. Cox wrote: I am using Apache::DBI on my test server - all OK. When I try to use it on my production server, I get the following- stdout: Shutting down httpd..done Starting httpd [ PERL ] Syntax OK stderr: /etc/init.d/apache: line 206: 18040 Segmentation fault $HTTPD_BIN $INET6 -t -f /etc/httpd/httpd.conf $MODULES /var/log/httpd/rcapache.log 21 ..failed [ .. ] BOTH the test and production servers are using: Apache/1.3.26 (Linux/SuSE) mod_perl/1.27 Linux/SuSE 8.1 - both with the latest patches. I can find nothing in the httpd logs. I know it must be some difference in my environment between the test and production servers, but I am at wits end on how to track this problem down. Could someone please push me in the right direction? Aloha = Beau. Are both servers running the latest versions of DBI and the relevant DBD::* driver? If not, try upgrading to see if that helps. -- best regards, randy kobes
RE: Apache::DBI seg fault
Randy - Thank you, I owe you lunch. I thought I checked all relevant module versions, but your msg spurred me to check again: DBI 1.28 was on production while DBI 1.30 was on test! 1.30 WORKS! 1.28 DOESN'T WORK. All is well - I am one happy camper ;) Aloha = Beau. -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 4:57 AM To: Beau E. Cox Cc: Modperl Subject: Re: Apache::DBI seg fault On Wed, 20 Nov 2002, Beau E. Cox wrote: I am using Apache::DBI on my test server - all OK. When I try to use it on my production server, I get the following- stdout: Shutting down httpd..done Starting httpd [ PERL ] Syntax OK stderr: /etc/init.d/apache: line 206: 18040 Segmentation fault $HTTPD_BIN $INET6 -t -f /etc/httpd/httpd.conf $MODULES /var/log/httpd/rcapache.log 21 ..failed [ .. ] BOTH the test and production servers are using: Apache/1.3.26 (Linux/SuSE) mod_perl/1.27 Linux/SuSE 8.1 - both with the latest patches. I can find nothing in the httpd logs. I know it must be some difference in my environment between the test and production servers, but I am at wits end on how to track this problem down. Could someone please push me in the right direction? Aloha = Beau. Are both servers running the latest versions of DBI and the relevant DBD::* driver? If not, try upgrading to see if that helps. -- best regards, randy kobes
Re: Apache::DBI and password security
On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of.
Re: Apache::DBI and password security
On Fri, 15 Nov 2002, Rafiq Ismail (ADMIN) wrote: On Fri, 15 Nov 2002, [iso-8859-1] Faßhauer, Wolfgang, FCI3 wrote: one database user because of resource limits. The problem I see is that the password for connecting to the database is clear readable in the perl script. Does anybody know how to hide that password? Have you thought of running your webserver as some 'www' user? You can then make your scripts readonly by a 'dev' group which the www user and the developes are members of. CORRECT: 'readonly' should be 'only readable' by R.
Re: Apache::DBI: number of mysql connections vary wildly
Hi there, On Thu, 17 Oct 2002, John Cameron wrote: I am finding that the number of open number of database connections I have open at one time is varying wildly. Then, Suddenly, the number of connctions jumps up to 50 or more! Sometimes this falls back to below 20, but sometimes this keeps climbing. Server load hits over 50 (99.9% taken by mysql) and the system grinds to a halt. Your Apache is spawning new children to serve multiple concurrent requests. It's supposed to do that. The extra children are opening connections to the database. When it has more children than it needs it kills off surplus ones which closes the extra database connections. If your machine can't handle the load you need to reduce the possible load. Check the value of MaxClients in httpd.conf. You can read more about this in the (admittedly intimidating:) documentation, see the mod_perl home page http://perl.apache.org for some links. 73, Ged.
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. Thanks for your advice, I am thinking besides the general advice I have received, Apache::DB will be my next most helpfull item. Eric At 02:33 PM 10/14/02 -0400, William McKee wrote: On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Hi, I had to read that over a few times to get it. And now I see that I do indeed have that situation, there are a number of times when I call my $holdstatus = new Holds(); from within a module that also has a new method. What I don't understand is how does my code work at all? Thanks, Eric At 07:13 PM 10/14/02 +0200, Rafiq Ismail wrote: On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED] (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
On 15 Oct 2002 at 7:12, Eric Frazier wrote: I am learning lots of new things, but still working on the problem itself. It seems to be the case that even when I am running under ./httpd -X I have trouble getting the search query to get stuck. If I do something from the mysql monitor like set an order on hold directly with a query, then the search results won't show the updated status of the order. Yet if from the web interface, I set the order on hold, then reload, the correct status is shown. If I restart apache, then the correct status shows. That sounds like trouble. The only problem I've had running httpd -X is when I compiled mod_ssl into my server. Apparently, it doesn't like to run in single processor mode (although I haven't confirmed this). Otherwise, the single processor mode should work just like multi-processor. I'd start looking into the code that checks that status. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com
Re: Apache::DBI for persistent connections
I was under the impression that Apache::DBI isn't compatible for this set up: win2000 + apache2.0.42 + perl5.8 + mod_perl1.99 For a multi threaded environment, isn't Apache::DBIPool necessary? I'd rather use Apache::DBI. Rafiq Ismail [EMAIL PROTECTED] wrote: On Tue, 15 Oct 2002, Paul Simon wrote: variables, such as the DBI handle, offer any benefits (or pain) of a shared connection?You might want to try using Apache::DBI for persistent connections.It is completely transparent to your code, in terms of changes.R.-- Senior ProgrammerBookings.nl--Me::[EMAIL PROTECTED]||www.dreamthought.comBudget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: Apache::DBI for persistent connections
Paul Simon wrote: I was under the impression that Apache::DBI isn't compatible for this set up: win2000 + apache2.0.42 + perl5.8 + mod_perl1.99 For a multi threaded environment, isn't Apache::DBIPool necessary? I'd rather use Apache::DBI. Apache::DBIPool doesn't actually exist yet. Apache::DBI will work correctly in a threaded environment if your DBD is thread-safe. Remember, no variables are shared between Perl threads unless you explicitly share them. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? Is the data that you're passing to the template correct? Throw in some warn statements. Run it in the debugger if you need to. - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
At 11:58 AM 10/14/02 -0400, Perrin Harkins wrote: Eric Frazier wrote: Here is the kind of thing that is driving me nuts. Please see: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed ies_for_Inner_Subroutines If what this says is true, then either I don't have a closure type problem, or else what is says isn't true. That documentation refers to one particular problem involving nested subs. You don't need to have nested subs to have closures, and closures may not even be the problem. You need to do some debugging. Narrow things down by verifying your assumptions one by one. Is CGI.pm really giving you the values you expect? (Some people have experienced issues with params not being reset when using CGI.pm in certain ways.) Is your SQL query being built correctly each time? I have checked the above, and I have lots of warns spaced around so I can watch things in the error log. Is the data that you're passing to the template correct? That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Thanks again, Eric Throw in some warn statements. Run it in the debugger if you need to. - Perrin (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin,
I am starting to feel guilty about bugging you so much, but you are the only
person to have responded, and I watch the list enough to value your advice
quite a bit.
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do the connect
in the new() vs up top outside of a sub.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
sub db_connect {
require DBI;
You don't need that. You should have already loaded it in startup.pl.
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
Probably should be in a config file, rather than buried in here.
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them
ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from
orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
I did this, I was a little scared about calling $dbh-finish() but I did
what you said, and yes life is good I don't notice a speed difference.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
I have no idea why I put off doing that for so long. But that is done now as
well.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
Eric Frazier wrote: I wanted the DBH to be global since just about every sub in Holds does a query of some sort. Three options: 1) Pass it to every sub 2) Make a utility sub that returns a dbh and call it from each sub. (Sounds like you already made one of these.) 3) Stuff it in $r-pnotes(), where it will get cleaned up after each request. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's been discussed quite a bit in various places. It is now documented in the perlobj man page: http://perldoc.com/perl5.8.0/pod/perlobj.html#Indirect-Object-Syntax - Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: Apache::DBI and CGI::Application with lots of modules. (fwd)
On Mon, 14 Oct 2002, Eric Frazier wrote: That looks like voodoo code copied from a man page. If you call this as Holds-new(), you don't need that junk about ref. (And most people recommend against the new Holds syntax.) I wanted the DBH to be global since just about every sub in Holds does a query of some sort. I guess it doesn't matter either way if I do the connect in the new() vs up top outside of a sub. Boredom break: As for your dbh, stick it whereever its scope applies, however I don't like declaring globals, so I've found that if I make the dbh accessible via an object, usually together with Apache::DBI in the background, I can often do clean up stuff, such as closing the handle (incase Apache::DBI isn't in place with a particular invokation of the package), last system logging updates/inserts, or whatever the job requires in a DESTROY method. What is the problem with the my $holdcheck = new Holds() type of syntax? I never read anything about that either way. It's in the book which I think should be called, 'the guy in the silly hat book,' ie. Damien's OO book, pretty much saying that, The indirect object syntax does, however, suffer from the same type of ambiguity problems that sometime befuddles print my $cd3 = new get_classname() (@data) #Compilation Error ... parapharased type=badly Assuming you have $cd=MyPackage and: get_name $cd; This is usually equivalent to: $cd-get_name; However, let's say that you have a method in the invoking script named 'get_name', then: get_name $cd; Gets interpreted as: get_name(MyPackage) Which is not what you're after. /paraphrase - from the guy in the silly hat book -- Senior Programmer Bookings.nl -- Me::[EMAIL PROTECTED]||www.dreamthought.com Budget hosting on my 10Mbit/backbone::[EMAIL PROTECTED]
Re: [cgiapp] Re: Apache::DBI and CGI::Application with lots of modules.
On 14 Oct 2002 at 9:12, Eric Frazier wrote: That I am not so sure of. I will do some more investigation. It seems like the only variables that could be causing this are the result set from the query and the scalar which holds the html template. I feel like I know absolutly nothing now :( I installed Apache::DB but don't yet know what to make of it. Hey Eric, I empathize with you! Getting myself up-to-speed with mod_perl development has been a demanding task. At the moment, my apps have stabilized but I'm sure to hit another hurdle down the road. As for Apache::DB, read the mod_perl guide at perl.apache.org. The debugger is a pain to learn but has helped me to solve several problems. There is good documentation on using the debugger in the camel book as well. One trick I learned was to let the script run through once using the 'c' command. That will load all the scripts and modules into memory which will let you set breaks in your code without having to watch every line go by. Also, I noticed some folks pointing out some global variables. If you're having troubles tracking these down in your script, you can see all the variables your script has instantiated by using perl-status and looking at the Loaded Modules. Find your CGI::App module in the list and click it to get a detailed list of the arrays, functions, hashes, etc. that it loads. Good luck, William -- Lead Developer Knowmad Services Inc. || Internet Applications Database Integration http://www.knowmad.com
RE: Apache::DBI and CGI::Application with lots of modules.
Hey Eric --
I wanted the DBH to be global since just about every sub in Holds does a
query of some sort. I guess it doesn't matter either way if I do
the connect
in the new() vs up top outside of a sub.
CGI::Application has a facility which is intended to solve exactly this type
of problem -- the param() method. The param() method allows you to stash a
property (such as a $dbh) in your CGI::Application-based object which can be
retrieved anywhere. I typically connect to the database in my setup()
method and stash my $dbh for use later:
package My::WebApp;
use strict;
use base qw/CGI::Application/;
sub setup {
my $self = shift;
$self-start_mode('start');
$self-run_modes(
'start' = 'run_mode_method'
);
my $dbh = $self-connect_to_database();
$self-param('DBH', $dbh);
}
sub run_mode_method {
my $self = shift;
# Get database handle
my $dbh = $self-param('DBH');
my $output = '';
# ...etc
return $output;
}
Furthermore, in order to disconnect, the teardown() method may be used:
sub teardown {
my $self = shift;
# Get database handle
my $dbh = $self-param('DBH');
$dbh-disconnect();
}
Refer to the CGI::Application POD for details on teardown() and param().
Regarding connecting to the database, I also urge you to encapsulate your
connection code. On my projects I always get things started by creating a
Perl module which I use whenever I need a database connection:
package My::DatabaseCreds;
use DBI;
sub new_dbh {
my $dbh = DBI-connect()
die (Can't connect: .$DBI::errstr) unless ($dbh);
return $dbh;
}
(This isn't exactly the code I use -- I actually have a module which I
sub-class, but you get the idea.)
The benefit of creating a module is that (1) all your Perl code can use this
module so that (2) should it ever have to change you can change it in one
place.
What is the problem with the my $holdcheck = new Holds() type of syntax?
I never read anything about that either way.
My guess is that Perrin was referring to your use of the indirect
notation, as opposed to the arrow notation:
Indirect:
my $holdcheck = new Holds()
Arrow:
my $holdcheck = Holds-new()
Many people (myself included) prefer the arrow notation. In general, the
arrow notation tends to be less ambiguous, particularly when it comes to
combining method calls with arguments.
HTH,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
Re: Apache::DBI and CGI::Application with lots of modules.
Hi,
Here is the kind of thing that is driving me nuts. Please see:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Remed
ies_for_Inner_Subroutines
If what this says is true, then either I don't have a closure type problem,
or else what is says isn't true. It says that
if I have this situation, I will get a warning. I am not getting any
warnings, but I am getting this behaviour with my search queries getting stuck
The only thing I do is again, copied from the perltoot
package Searches;
use strict;
use Carp;
use vars qw($dbh);
use gentimeid; # generate time id based
use Calc_Price; # get totals
use warnings;
# use DBIx::XHTML_Table; # maybe later
use QueryPrint;
#use Data::Dumper;
# These searches are restricted to user level searches, there will be a
admin level search for
# managment reports
$dbh = db_connect();
# requires a $q query object to be init.
sub new {
my $self = {};
my $proto = shift;
my $class = ref($proto) || $proto;
$self-{queryobject} = undef;
$self-{isDomestic} = undef;
$self-{isInternational} = undef;
$self-{isShippingSame} = undef;
$self-{CustIsInserted} = undef;
$self-{OrderIsInserted} = undef;
$self-{CustNum} = undef;
$self-{OrderNum} = undef;
bless ($self, $class);
return $self;
}
sub queryobject {
my $self = shift;
if (_) { $self-{queryobject} = shift }
return $self-{queryobject};
}
Other stuff not used yet
sub LookupOrder {
my $self = shift;
my $q = $self-{queryobject};
my $output = '';
my $hasparameter = 0;
... Build a query from CGI.pm vars passed in though queryobject
...
$order_name_qu .= ORDER BY $orderby ; # the query string is here
if ($hasparameter == 1) { # if something was filled in the search form
my $sth = $dbh-prepare($order_name_qu) or confess(Main search
failed $order_name_qu);
$sth-execute() or confess(Main search failed $order_name_qu);
my $headers = $sth-{'NAME'};
my rows= $sth-fetchall_arrayref();
my $resulthtml = new QueryPrint(ResultSet = rows,
Action = 'customer',
ColumnList = $headers);
my $html = $resulthtml-SetAction(); # sets a template type in the
QueryPrint module
$output = $resulthtml-QueryPrint();
$sth-finish();
#warn QUERY - $order_name_qu;
undef rows;
undef $resulthtml;
undef $order_name_qu;
return $output;
} else {
return no query to do;
}
Then this is all called from my CGI::Application module
sub customer_display{
my $self = shift;
my $q = $self-query();
my $customersearch = new Searches();
$customersearch-queryobject($q); # set the query
my $header = parse_header($self);
return $header . $customersearch-LookupCustName();
}
So going nuts now, where is the problem? My QueryPrint module is pretty
much the same, so if this is ok, it should be as well.
Thanks,
Eric
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
All I have read says that because I am using oop
modules and use strict along with use vars that should not happen.
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q-param('holdstate');
display_holdtype();
sub display_holdtype {
print holdtype: $holdtype in process $$\n;
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
(250) 655 - 9513 (PST Time Zone)
Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI and CGI::Application with lots of modules.
I'm just going to point out a few problems. These are not all related
to your questions.
package Holds;
The case of Holds doesn't match the example sub you posted above. I'm
assuming that was a typo.
use strict;
use Carp;
use warnings;
use QueryPrint;
use vars qw($dbh $processed_hnd $status_hnd);
use gentimeid; # generate time id based
sub new {
my $invocant = shift;
my $class = ref($invocant) || $invocant;
That looks like voodoo code copied from a man page. If you call this as
Holds-new(), you don't need that junk about ref. (And most people
recommend against the new Holds syntax.)
my $self = { _ };
bless ($self, $class);
$dbh = db_connect();
You don't seem to need this. You aren't using the database handle for
anything in this sub and you aren't gaining anything by calling it here.
sub GetProcessed {
my $self = shift;
This has a bug, somtimes the cached query doesn't stick around.
If you lose your database connection, Apache::DBI will reconnect. Any
prepared queries will be lost. You *must* prepare every time, but see
below...
sub db_connect {
require DBI;
You don't need that. You should have already loaded it in startup.pl.
my $dbname = 'CS';
my ($dbuser, $dbpasswd) = ('myuser', 'mypass');
Probably should be in a config file, rather than buried in here.
my $dbh = DBI-connect(DBI:mysql:$dbname, $dbuser, $dbpasswd)
or die can't connect: $DBI::errstr\n;
# we need these waiting for queries, so we are going to prepare them ahead of
time, and yes
# horror of horror they will be global. Sorry Mom I tried :(
$processed_hnd = $dbh-prepare_cached(select ord_tpak_processed from orders
where ord_num=?) or confess(can't get tpak processed);
$status_hnd = $dbh-prepare_cached(select is_hold_set,holdstate from
holds where ord_num=?) or confess(can't get hold status);
#DBI-trace(2,/usr/local/apache/htdocs/out.log);
return $dbh;
Don't put those in globals. The prepare_cached call already stores them
for the life of your database connection. Apache::DBI will keep that
connection alive (in a global hash) as long as it can and reconnect if
the connection is lost. If the connection does get lost, the statement
handles in these globals will stop working. You do recreate them every
time since you call this sub every time, but you could lose the
connection between the time this sub is called and the time you use
these handles.
2. Every once in a while I get an out of memory error.
You can control process growth over time in a number of ways. They are
documented in the mod_perl guide.
3. My main search result page is getting cached, the closure type of
problem.
Are you using any modules that have subs with sub ref prototypes, like
Error.pm? That can do it.
All I have read says that because I am using oop
modules and use strict along with use vars that should not happen.
It's actually really easy to create closures. Here is a closure:
my $holdtype = $q-param('holdstate');
display_holdtype();
sub display_holdtype {
print holdtype: $holdtype in process $$\n;
}
This will always print whatever the value was the first time, no matter
what you change it to later. (The first time for that process, that
is.) Watch out for things like that. You should always pass params
explicitly.
4. I know the way I have done these db connects is sloppy. But I can't seem
to find a better way. Could I make one db_connect sub,and inherite it all
though my modules?
Make one sub that returns a database handle and use it from everywhere.
Doesn't need to be inherited, you can just stick it in a module that
all the other modules call.
Hope some of that was helpful,
Perrin
Re: Apache::DBI and CGI::Application with lots of modules.
Perrin, I am going to read over this closely, thanks for all of the advice! What frustrats me about the search getting cached/closure thing is that I just don't have any global variables that have anything to do at all with the search results. I have read over and over examples with closures, recognize the example you included as one, but I still can't seem to find it in my own code. I guess I need to take a fresh look again. I did -X httpd and it is happening every time. I think part of what is getting me is I have used mod_perl for smaller things, but now it is a pretty big system. I don't seem to be able to get away with as much :) Also, I am really trying to bring my code level up a notch, but as you pointed out, there are some things I am doing that I don't really understand well enough yet. Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: Apache::DBI new connects in error_log...
On Tue, 3 Sep 2002 10:36:30 -0700 (PDT) Anthony E. [EMAIL PROTECTED] wrote: --- Enrico Sorcinelli [EMAIL PROTECTED] wrote: On Tue, 3 Sep 2002 09:05:45 -0700 (PDT) Anthony E. [EMAIL PROTECTED] wrote: Hello, I'm getting an awful lot of these error statements in my error_log file for apache: -- 25935 Apache::DBI new connect to 'db:1.2.3.4UserPassAutoCommit=1PrintError=1' -- It looks like they are happening for every database connection, like the db connections are not staying persistent. I'm using Apache::DBI in my startup.pl script under mod_perl. Also the web server has been crashing every 10 minutes, when the server load gets up to about 105. any ideas? There are some additional informations that you should supply in order to help you, like - Are connections per-user? How to i tell? Hi Anthony, Apache::DBI caches connection based on his args (dbd driver, user, password...) and attributes. So, if your application uses a different user and/or attributes to connect to (a different?) database, every connection will be cached. Also, every child could have these cached DB's handles. Apache::DBI works very well for web applications that uses same DB user. - Have you loaded Apache::DBI before DBI or before any module that load it? Yes, in startup.pl. This doesn't assure that you have loaded it before! For instance if you have in your httpd.conf: PerlModule DBI (or any module that uses it) before PerlRequire /path/to/startup.pl or load DBI (or any module that uses it) before Apache::DBI in your startup.pl script. - How many childs? (with Apache::DBI 1 child = 1 connection) How to i tell? On Unix/Linux you can do this: ps -A | grep -c httpd Bye - Enrico [OT]: The 2.11-13 paragraphs of mod_perl developers cookbook are a good recipe! (if you are a mod_perl developer you must to have it! ;-)
Re: Apache::DBI new connects in error_log...
On Tue, 3 Sep 2002 09:05:45 -0700 (PDT) Anthony E. [EMAIL PROTECTED] wrote: Hello, I'm getting an awful lot of these error statements in my error_log file for apache: -- 25935 Apache::DBI new connect to 'db:1.2.3.4UserPassAutoCommit=1PrintError=1' -- It looks like they are happening for every database connection, like the db connections are not staying persistent. I'm using Apache::DBI in my startup.pl script under mod_perl. Also the web server has been crashing every 10 minutes, when the server load gets up to about 105. any ideas? There are some additional informations that you should supply in order to help you, like - Are connections per-user? - Have you loaded Apache::DBI before DBI or before any module that load it? - How many childs? (with Apache::DBI 1 child = 1 connection) - Software version (Apache, Perl, mod_perl, DBI and Apache::DBI) of course Bye - Enrico
Re: Fwd: Re: Apache::DBI as a prerequisite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 30, 2002 10:02 pm, Stas Bekman wrote: 2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html Though you can really rely on it once Apache::Test is released, which will happen when mod_perl 2.0 is released. 1) That's an interesting problem. It seems that nobody has asked this question before. Here is my take on it. If you like this solution I'll add it to the docs. Thanks a lot. Your solution for Apache::DBI works and is very Perlish! - -- Simon Perreault [EMAIL PROTECTED] Web: http://www.linuxquebec.com/~nomis80 PGP: $Web/nomis80.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9R94IqaCdwBMK2KkRAn9IAKCJ7UlIztV6MlThz8Y79b7+FbEGAQCZAdE+ 3yP5wB/0udz2Rkgkvh+2S4U= =ETSh -END PGP SIGNATURE-
Re: Fwd: Re: Apache::DBI as a prerequisite
Simon Perrault wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 30, 2002 10:02 pm, Stas Bekman wrote: 2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html Though you can really rely on it once Apache::Test is released, which will happen when mod_perl 2.0 is released. 1) That's an interesting problem. It seems that nobody has asked this question before. Here is my take on it. If you like this solution I'll add it to the docs. Thanks a lot. Your solution for Apache::DBI works and is very Perlish! Great. I've put it here: http://perl.apache.org/docs/general/cpan_mod_dev/cpan_mod_dev.html __ 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
Fwd: Re: Apache::DBI as a prerequisite
Could you please take a look at this problem? Thanks.
- Forwarded message from Stas Bekman [EMAIL PROTECTED] -
Date: Mon, 29 Jul 2002 09:56:05 +0800
From: Stas Bekman [EMAIL PROTECTED]
Reply-To: Stas Bekman [EMAIL PROTECTED]
Subject: Re: Apache::DBI as a prerequisite
To: Simon Perrault [EMAIL PROTECTED]
Simon, please repost to the modperl list and we will discuss it there.
Thanks.
Simon Perrault wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
while not under mod_perl. You said this:
That's normal. You cannot test modules that use mod_perl API without
running them inside mod_perl server. I've the same problem as you've
reported. This test suite is simple broken.
...
All Apache:: module authors should be moving to use the new Apache::Test
framework soon, since it lets you test the code under running mod_perl
server and works with both versions of httpd/mod_perl.
This is exactly my situation. I develop a module which requires Apache::DBI,
so I include it in my Makefile.PL like this:
WriteMakefile(
'PREREQ_PM'= {
'Apache::DBI' = 0,
},
);
But that prints a warning because Apache::DBI can't find Apache::module(),
which is only available under mod_perl.
My question:
1) Can you tell me (or guide me toward some information) how I can properly
add Apache::DBI as a prerequisite so that it doesn't print a warning (which
is the subjet of 90% of user emails)?
2) How can I test my module running Apache::DBI with Apache::Test?
Thanks a lot
- --
Simon Perreault [EMAIL PROTECTED]
Web: http://www.linuxquebec.com/~nomis80
PGP: $Web/nomis80.gpg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9QwYAqaCdwBMK2KkRAt+pAJ9knR94Tz5jmBFCyO/hL/fNWwHzmwCfZSl0
66Chb76wE6YcgR6JbxYpQEc=
=4xfy
-END PGP SIGNATURE-
--
__
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
- End forwarded message -
--
Simon Perreault [EMAIL PROTECTED]
Web: http://www.linuxquebec.com/~nomis80
PGP: $Web/nomis80.gpg
Re: Fwd: Re: Apache::DBI as a prerequisite
Simon Perreault wrote:
You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
while not under mod_perl. You said this:
That's normal. You cannot test modules that use mod_perl API without
running them inside mod_perl server. I've the same problem as you've
reported. This test suite is simple broken.
...
All Apache:: module authors should be moving to use the new Apache::Test
framework soon, since it lets you test the code under running mod_perl
server and works with both versions of httpd/mod_perl.
This is exactly my situation. I develop a module which requires Apache::DBI,
so I include it in my Makefile.PL like this:
WriteMakefile(
'PREREQ_PM'= {
'Apache::DBI' = 0,
},
);
But that prints a warning because Apache::DBI can't find Apache::module(),
which is only available under mod_perl.
My question:
1) Can you tell me (or guide me toward some information) how I can properly
add Apache::DBI as a prerequisite so that it doesn't print a warning (which
is the subjet of 90% of user emails)?
2) How can I test my module running Apache::DBI with Apache::Test?
I'll answer these in reverse:
2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html
Though you can really rely on it once Apache::Test is released, which
will happen when mod_perl 2.0 is released.
1) That's an interesting problem. It seems that nobody has asked this
question before. Here is my take on it. If you like this solution I'll
add it to the docs.
Makefile.PL
---
use ExtUtils::MakeMaker;
# set prerequisites
my %prereq = (
Foo = 1.56,
);
# Manually test whether Apache::DBI is installed and add it to the
# PREREQ_PM if it's not installed, so CPAN.pm will automatically fetch
# it. If Apache::DBI is already installed it will fail to get loaded by
# MakeMaker because it requires the mod_perl environment to load.
eval { require Apache::DBI };
if ($@ $@ !~ /Can't locate object method/) {
$prereq{Apache::DBI} = '';
}
WriteMakefile(
NAME = 'Apache::SuperDuper',
VERSION_FROM = 'SuperDuper.pm',
PREREQ_PM = \%prereq,
# ...
);
__
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
Re: Apache::DBI with mod_perl 2.0
Ok, still no luck. Every dependancy has more dependancies all of which go
back and back to mod_perl 1 stuff already being in place
My question is, can I download the Apache 1.3 source (don't make it), then
run the mod_perl 1 build to get all the pm files in place, then rebuild my
mod_perl 2 (against my installed Apache 2 source).
Also, we mentioned the whole Bundle::Apache, will there be one of those
for Apache 2 and will it contain all the mod_perl 1 AND mod_perl 2 stuff to
allow running in Compat?
Thanks,
-Zac
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: Zac Morris [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 12:26 PM
Subject: Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc that contains all the kludges or
assumed modules I need to already have in place?
All the docs that we have now are at
http://perl.apache.org/release/docs/index.html
Most of the kludges are documented here:
http://perl.apache.org/release/docs/2.0/user/compat/compat.html
There are much more to come, but it'll take time. For now there is more
than enough docs to get yourself started. If something is unclear or
missing please shout aloud.
I'm assuming that the bulk of these things are handled via a CPAN
Apache::bundle install, and because mod_perl2 is still beta we don't
have
that in place yet?
yes, but Apache::Module is an XS module using mod_perl 1.0's API, so it
won't be in the Apache::Bundle for 2.0. This patch may go in soon:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.61
diff -u -r1.61 compat.pm
--- lib/Apache/compat.pm 4 Jun 2002 12:40:53 - 1.61
+++ lib/Apache/compat.pm 25 Jun 2002 15:17:56 -
@@ -91,7 +91,8 @@
}
sub module {
-require Apache::Module;
+eval { require Apache::Module };
+die Please install Apache::Module from CPAN if $@;
return Apache::Module::loaded($_[1]);
}
Thanks for all this info, learning more and more every day. :)
cool :)
__
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
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, still no luck. Every dependancy has more dependancies all of which go back and back to mod_perl 1 stuff already being in place My question is, can I download the Apache 1.3 source (don't make it), then run the mod_perl 1 build to get all the pm files in place, then rebuild my mod_perl 2 (against my installed Apache 2 source). Sorry Zac, my diagnosis and patch were wrong. mod_perl 2.0's compat layer doesn't require mod_perl 1.0 to be installed, sorry for confusing people. Apache::Module *is* in 2.0. But for some reason it didn't work for you. So let's try to investigate why. It seems to me that you have Apache::Module for 1.0 installed and it gets loaded instead of 2.0's version. Can you list all Apache/Module found on your machine (pm, so, etc)? locate Apache/Module I'm certain that if you install mod_perl 2.0 into Apache2/ dirs (even though you don't have mod_perl 1.0 installed) this problem will go away. But I'd still like to figure out what kind of collission you have now. Also, we mentioned the whole Bundle::Apache, will there be one of those for Apache 2 and will it contain all the mod_perl 1 AND mod_perl 2 stuff to allow running in Compat? no, it'll contain only stuff needed for 2.0, which may include modules that work for both mod_perls, but definitely not mod_perl 1.0. Again I apologize for my mistake. __ 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
Re: Apache::DBI with mod_perl 2.0
Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? Thanks, -Zac
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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
Re: Apache::DBI with mod_perl 2.0
Ahhh, ok more clarity. :) Forgive me if I'm just not doing my detective work in poking around for documentation, but is there a doc that contains all the kludges or assumed modules I need to already have in place? I'm assuming that the bulk of these things are handled via a CPAN Apache::bundle install, and because mod_perl2 is still beta we don't have that in place yet? Thanks for all this info, learning more and more every day. :) -Zac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 11:02 AM Subject: Re: Apache::DBI with mod_perl 2.0 Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc that contains all the kludges or
assumed modules I need to already have in place?
All the docs that we have now are at
http://perl.apache.org/release/docs/index.html
Most of the kludges are documented here:
http://perl.apache.org/release/docs/2.0/user/compat/compat.html
There are much more to come, but it'll take time. For now there is more
than enough docs to get yourself started. If something is unclear or
missing please shout aloud.
I'm assuming that the bulk of these things are handled via a CPAN
Apache::bundle install, and because mod_perl2 is still beta we don't have
that in place yet?
yes, but Apache::Module is an XS module using mod_perl 1.0's API, so it
won't be in the Apache::Bundle for 2.0. This patch may go in soon:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.61
diff -u -r1.61 compat.pm
--- lib/Apache/compat.pm4 Jun 2002 12:40:53 - 1.61
+++ lib/Apache/compat.pm25 Jun 2002 15:17:56 -
@@ -91,7 +91,8 @@
}
sub module {
-require Apache::Module;
+eval { require Apache::Module };
+die Please install Apache::Module from CPAN if $@;
return Apache::Module::loaded($_[1]);
}
Thanks for all this info, learning more and more every day. :)
cool :)
__
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
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 00:49 23.06.2002, Charles Aulds wrote: At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Great! Seems like Apache::compat is working as a charm. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Server Version: Apache/2.0.36 (Unix) mod_perl/1.99_03-dev Perl/v5.6.1 DAV/2 Using Per Ellesfsen's suggests, and also pre-loading the following startup.pl script (for compat.pm): #!/usr/bin/perl -w use strict; use Apache2(); use Apache::compat; 1; Rudimentary benchmarks, using a MySQL server, and very simple query, shows that Apache::DBI significantly reduces user response time, and increases the throughput of the server (a very limited single P200 MX system, with only 64MB RAM running RH 7.3): Table 8.2: Benchmarking Results Using Database Connection Sharing CGImod_perl Server Hostname192.168.1.1192.168.1.1 Server Port8080 Document Path/cgi-bin/zipcodes.cgi?zip=35801/perl/zipcodes.cgi?zip=35801 Concurrency Level1010 Elapsed Time258.722seconds63.691 seconds Complete Requests200200 Failed Requests00 Total Transferred127000 bytes131843 bytes HTML Transferred89200 bytes90200 bytes Requests per Second0.773.20 Median Connection Times 12518 ms424 ms Transfer Rate0.48Kbps received2.05Kbps received --- Charles Aulds, MCSE, MCP+I Voice: (256) 931-5593 Fax: (240) 352-8290 http://hiwaay.net/~caulds
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Server Version: Apache/2.0.36 (Unix) mod_perl/1.99_03-dev Perl/v5.6.1 DAV/2 Using Per Ellesfsen's suggests, and also pre-loading the following startup.pl script (for compat.pm): #!/usr/bin/perl -w use strict; use Apache2(); use Apache::compat; 1; Rudimentary benchmarks, using a MySQL server, and very simple query, shows that Apache::DBI significantly reduces user response time, and increases the throughput of the server (a very limited single P200 MX system, with only 64MB RAM running RH 7.3): CGImod_perl Server Hostname192.168.1.1192.168.1.1 Server Port8080 Document Path/cgi-bin/zipcodes.cg /perl/zipcodes.cgi? zip=35801 zip=35801 Concurrency Level1010 Elapsed Time258.722seconds63.691 seconds Complete Requests200200 Failed Requests00 Total Transferred127000 bytes131843 bytes HTML Transferred89200 bytes90200 bytes Requests per Second0.773.20 Median Connection Times 12518 ms424 ms Transfer Rate0.48Kbps received2.05Kbps received --- Charles Aulds, MCSE, MCP+I Voice: (256) 931-5593 Fax: (240) 352-8290 http://hiwaay.net/~caulds
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 18:26 21.06.2002, Zac Morris wrote: I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). You will probably also want to see the 2.0 docs at http://perl.apache.org/release/docs/ Good luck! -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
Per Einar Ellefsen wrote: At 18:26 21.06.2002, Zac Morris wrote: I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules in your httpd.conf, before loading other modules (like Apache::DBI). You will probably also want to see the 2.0 docs at http://perl.apache.org/release/docs/ start here: http://perl.apache.org/release/docs/2.0/user/intro/start_fast.html but since it seems that you've it installed already, proceed here: http://perl.apache.org/release/docs/2.0/user/config/config.html#Enabling_mod_perl though I haven't tried, you should be able to use Apache::DBI with the compat layer and preforked mpm/ __ 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
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules Nope, he did a clean mod_perl 2 install, without MP_INST_APACHE2 I think... so doesn't have an Apache.pm because mod_perl 1 wasn't installed before. ah, ok then, but most likely MP_INST_APACHE2 is going to be the default, so if later you need to install mod_perl 1.0 you don't have to wipe your 2.0 install first. so better start getting used to it :) -- __ 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
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 19:46 21.06.2002, Stas Bekman wrote: Per Einar Ellefsen wrote: At 18:26 21.06.2002, Zac Morris wrote: I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules Nope, he did a clean mod_perl 2 install, without MP_INST_APACHE2 I think... so doesn't have an Apache.pm because mod_perl 1 wasn't installed before. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache::DBI connection cache
Ask Bjoern Hansen wrote:
Apache::DBI is turning the argument hashref into the cache key
with the following code,
my ($key, $val);
while (($key,$val) = each %{$args[3]}) {
$Idx .= $;$key=$val;
}
can anyone think of a good reason not to change that to something
like
map { $Idx .= $;$_=$args[3]-{$_} } sort keys %{$args[3]};
Good find. That's a bug. Fix it.
- Perrin
Re: Apache::DBI connection cache
On Wed, 22 May 2002, Perrin Harkins wrote:
Apache::DBI is turning the argument hashref into the cache key
with the following code,
[...]
can anyone think of a good reason not to change that to something
like
map { $Idx .= $;$_=$args[3]-{$_} } sort keys %{$args[3]};
Good find. That's a bug. Fix it.
I sent a patch to Edmund.
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Apache::DBI connection cache
Ask Bjoern Hansen wrote:
Apache::DBI is turning the argument hashref into the cache key
with the following code,
my ($key, $val);
while (($key,$val) = each %{$args[3]}) {
$Idx .= $;$key=$val;
}
can anyone think of a good reason not to change that to something
like
map { $Idx .= $;$_=$args[3]-{$_} } sort keys %{$args[3]};
(or a similar for loop)
(My problem, obviously, was that Apache::DBI got several connections
to the same database with the same args; but the hash had the args
ordered in a different way.)
FWIW, this code was borrowed right from DBI (at least I think it was).
see the very end of Tim's recent (5/1/2002) message here
http:[EMAIL PROTECTED]/msg11273.html
to see how DBI connect_cached() now handles it (and Tim's suggested
change to Apache::DBI).
HTH
--Geoff
Re: Apache::DBI
Gregory Matthews wrote: Does this mean if each user has to use a unique username/password to OPEN the database? Yes, eaxctly. My prog will use the same database:username:password for all connection requests opened with a db_connect($database,$user,$password) call, however, each user will have his/her own unique file/table within this database which requires a unique username/password to access. So that security is handled by your program, not by the database? No problem for Apache::DBI logins then. - Perrin
Re: Apache::DBI
Perrin: Yes, my prog checks for valid username/password requests and issues the proper response. So it sounds like Apache::DBI is a good solution then since all users will be working under the same handle? Gregory At 02:03 PM 5/18/2002 -0400, you wrote: Gregory Matthews wrote: Does this mean if each user has to use a unique username/password to OPEN the database? Yes, eaxctly. My prog will use the same database:username:password for all connection requests opened with a db_connect($database,$user,$password) call, however, each user will have his/her own unique file/table within this database which requires a unique username/password to access. So that security is handled by your program, not by the database? No problem for Apache::DBI logins then. - Perrin
Re: Apache::DBI
Gregory Matthews wrote: Yes, my prog checks for valid username/password requests and issues the proper response. So it sounds like Apache::DBI is a good solution then since all users will be working under the same handle? Yes, that's correct.
Re: Apache::DBI
At 19:59 18.05.2002, Gregory Matthews wrote: Hello again: I figured out my Apache::DB problem with the help from Stas Bekman. Thanks! Now on to Apache::DBI. The documentation says NOT to use this module IF you are opening a special connection for each of your users. Does this mean if each user has to use a unique username/password to OPEN the database? My prog will use the same database:username:password for all connection requests opened with a db_connect($database,$user,$password) call, however, each user will have his/her own unique file/table within this database which requires a unique username/password to access. I am assuming that this means I CAN use the Apache::DBI module. Yes. Apache::DBI refers to user as the $user variable you mentioned. For example, if there was something equivalent to what phpMyAdmin does under PHP, that would not be a good idea for using Apache::DBI -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache::DBI fails to compile?
F.Xavier Noria wrote: I installed Apache::DBI and make test run no test, but the make test of Apache::AuthCookieDBI tries to use Apache::DBI and fails because Apache/DBI.pm in line 202 invokes Apache-module(), which it seems it is not in the interface of the Apache class I have installed: $ perl -MApache::DBI -e1 Can't locate object method module via package Apache (perhaps you forgot to load Apache?) at /usr/local/share/perl/5.6.1/Apache/DBI.pm line 202. Compilation failed in require. BEGIN failed--compilation aborted. This is the version of Apache.pm I have installed: $ perl -MApache -le 'print $Apache::VERSION' 1.27 and mod_perl is 1.26, do you know what could wrong? That's normal. You cannot test modules that use mod_perl API without running them inside mod_perl server. I've the same problem as you've reported. This test suite is simple broken. If you talk to the Jacob Davies, please tell him that it's a good idea to set the prerequisites in Makefile.PL, so his module will be installable from CPAN, without doing any manual work. All Apache:: module authors should be moving to use the new Apache::Test framework soon, since it lets you test the code under running mod_perl server and works with both versions of httpd/mod_perl. __ 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
Re: Apache::DBI or What ?
Hi! Thanks a lot for this. I am not sure now if I will be able to use it. I am afraid that if I do I will suddenly become its main supporter :) I also still don't see how a connection can be reconnected at such a high level. Even when I looked into the mySQL C api I didn't see anything that would help, which ment that the real stuff was barried deeper still. But the caching of connection handles makes sense, and that might still be worth while. Between this and mod_accel I have a lot to mess with. Thanks, Eric At 01:52 PM 3/30/02 -0500, Hank Leininger wrote: On 2002-03-27, Eric Frazier [EMAIL PROTECTED] wrote: If you have any idea where to find this code I would be thankful. I can only find this.. [snip] At 04:47 PM 3/26/02 -0500, John D Groenveld wrote: Jeff Horn posted this a couple years ago either here or @ dbi-users # Purpose: This version of Apache::DBI maintains a SINGLE persistent # connection to each database. When the user changes on Ask and ye shall receive ;) http://marc.theaimsgroup.com/?l=apache-modperlm=96614841600181w=2 Or just grab the last attachment, which is the replacement DBI.pm: http://marc.theaimsgroup.com/?l=apache-modperlm=96614841600181q=p6 -- Hank Leininger [EMAIL PROTECTED] http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Re: Apache::DBI or What ?
Eric Frazier wrote: I also still don't see how a connection can be reconnected at such a high level. It can't, unless your database specifically supports the command reauthenticate. Oracle does, which is what he wrote this for, but I don't think it's a standard part of SQL syntax so it will probably not work with MySQL. Of course MySQL connects really quickly, so you can probably get perfectly good performance without using Apache::DBI at all. - Perrin
Re: Apache::DBI or What ?
On 2002-03-27, Eric Frazier [EMAIL PROTECTED] wrote: If you have any idea where to find this code I would be thankful. I can only find this.. [snip] At 04:47 PM 3/26/02 -0500, John D Groenveld wrote: Jeff Horn posted this a couple years ago either here or @ dbi-users # Purpose: This version of Apache::DBI maintains a SINGLE persistent # connection to each database. When the user changes on Ask and ye shall receive ;) http://marc.theaimsgroup.com/?l=apache-modperlm=96614841600181w=2 Or just grab the last attachment, which is the replacement DBI.pm: http://marc.theaimsgroup.com/?l=apache-modperlm=96614841600181q=p6 -- Hank Leininger [EMAIL PROTECTED]
Re: Apache::DBI or What ?
There are databases that allow you to change the current user without reconnecting. In fact someone posted a module to do this a while back, but I can't remember which database it was for. Seems like it was Sybase or Informix. Jeff Horn posted this a couple years ago either here or @ dbi-users # Hacked Up Version of Apache::DBI # # Hacking by: Jeff Horn ([EMAIL PROTECTED]) # # Purpose: This version of Apache::DBI maintains a SINGLE persistent # connection to each database. When the user changes on # subsequent connect calls, the DBI-func( ., ., 'reauthtenticate') # is called to quickly authenticate the new user on the existing # connection. I've used it for a few projects, I haven't really follow how changes over the last year to Edmund Mergl's Apache::DBI or Tim Bunce's DBI may have affected it. I recall one problem being when using different attributes to connect methods. Have fun. John [EMAIL PROTECTED]
Re: Apache::DBI or What ?
Hi, If you have any idea where to find this code I would be thankful. I can only find this.. http://aspn.activestate.com/ASPN/Mail/Message/perl-DBI/298774 Thanks, Eric At 04:47 PM 3/26/02 -0500, John D Groenveld wrote: There are databases that allow you to change the current user without reconnecting. In fact someone posted a module to do this a while back, but I can't remember which database it was for. Seems like it was Sybase or Informix. Jeff Horn posted this a couple years ago either here or @ dbi-users # Hacked Up Version of Apache::DBI # # Hacking by: Jeff Horn ([EMAIL PROTECTED]) # # Purpose: This version of Apache::DBI maintains a SINGLE persistent # connection to each database. When the user changes on # subsequent connect calls, the DBI-func( ., ., 'reauthtenticate') # is called to quickly authenticate the new user on the existing # connection. I've used it for a few projects, I haven't really follow how changes over the last year to Edmund Mergl's Apache::DBI or Tim Bunce's DBI may have affected it. I recall one problem being when using different attributes to connect methods. Have fun. John [EMAIL PROTECTED] http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Learn about the net, not the .Net!
Re: Apache::DBI or What ?
On Sun, 24 Mar 2002, Andrew Ho wrote: What would be ideal is if the database would allow you to change the user on the current connection. I know PostgreSQL will allow this using the command line interface psql tool (just do \connect database user), but I'm not sure if you can do this using DBI. Does anyone know if any datbases support this sort of thing? This occurred to me in the case of Oracle (one of my co-workers was facing a very similar problem in the preliminary stages of one of his designs), and I actually had asked our DBAs about this (since the Oracle SQL*Plus also allows you to change users). As I suspected (from the similar connect terminology), our DBAs confirmed that Oracle just does a disconnect and reconnect under the hood. I would bet the psql client does the same thing. First, I'll suggest that there are hopefully other areas you can look at optimizing that will get you a bigger bang for your time - in my test environment (old hardware), it takes 7.4 ms per disconnect/reconnect/rebind and 4.8 ms per rebind. Admittedly, I'm dealing with LDAP instead of SQL, and I've no idea how they compare. If the TCP connection were retained, this could still be a significant win. *Any* reduction in the connection overhead is an improvement. If there are a million connects per day, and this saves a milli-second per connect (believable to me, as at least three packets don't need to be sent - syn, syn ack, and fin. My TCP's a bit fuzzy, but I think there's a couple more, and there's also the mod_perl disconnect/reconnect overhead), that's over 15 minutes of response time and about 560,000,000 bits of network bandwidth (assuming the DB is not on the same machine) saved. Admittedly, at 100Mb/s, that's only 6 seconds. It may, in some cases, still be necessary to move access control from the DB into ones application, so one can maintain a single connection which never rebinds, but I think it's better to utilize the security in the DB instead of coding ones own - more eyes have looked over it. We're talking about a fairly small unit of time; it may very well be better to throw money if you are near your performance limit. Ed
Re: Apache::DBI or What ?
Hi, It might well be that in my particular case, I don't have anything to worry about the connection time per each user most likely won't kill me or even cause problems at first. But I am trying to build a system, and I don't want to skip any reasonable efficences I can build in from the start. In my situation the user will only be doing inserts from the mod_perl side, so I am thinking I can make use of something like Apache::File or some kind of tmp file where I will store the tab delimited data for the user insert, and on the cleanup handler phase does a COPY FROM file which is a Postgress thing to the user's table. I need for that data to be available to that same user by JDBC pretty much immediatly. But does a copy from a file like this work better than a persistent connection but one that is doing insert after insert which is not nearly as efficent as the bulk copy? As I understand it the COPY from after a droping indexes would be the fastest way to insert data into a table for postgress, period. I guess I will just have to test it out and see. The other thing I am wondering about, is that even if I have a bunch of users, why couldn't I just make my persistent connection user have rights to all of the other user tables? Well, I guess I could do that, but I am expecting one of you will tell me why that is a bad idea :) Something about it seem too easy after all of this. I was tending to want to use the DBs security also for the same reasons, so maybe that is what bothers me about the above. Thanks, this discussion has helped me out tremendously, just to know others have the same problem even. Eric First, I'll suggest that there are hopefully other areas you can look at optimizing that will get you a bigger bang for your time - in my test environment (old hardware), it takes 7.4 ms per disconnect/reconnect/rebind and 4.8 ms per rebind. Admittedly, I'm dealing with LDAP instead of SQL, and I've no idea how they compare. If the TCP connection were retained, this could still be a significant win. *Any* reduction in the connection overhead is an improvement. If there are a million connects per day, and this saves a milli-second per connect (believable to me, as at least three packets don't need to be sent - syn, syn ack, and fin. My TCP's a bit fuzzy, but I think there's a couple more, and there's also the mod_perl disconnect/reconnect overhead), that's over 15 minutes of response time and about 560,000,000 bits of network bandwidth (assuming the DB is not on the same machine) saved. Admittedly, at 100Mb/s, that's only 6 seconds. It may, in some cases, still be necessary to move access control from the DB into ones application, so one can maintain a single connection which never rebinds, but I think it's better to utilize the security in the DB instead of coding ones own - more eyes have looked over it. We're talking about a fairly small unit of time; it may very well be better to throw money if you are near your performance limit. Ed http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone)
Re: Apache::DBI or What ?
Ed Grimm wrote: First, I'll suggest that there are hopefully other areas you can look at optimizing that will get you a bigger bang for your time - in my test environment (old hardware), it takes 7.4 ms per disconnect/reconnect/rebind and 4.8 ms per rebind. Admittedly, I'm dealing with LDAP instead of SQL, and I've no idea how they compare. Connecting to Oracle can take 30 seconds on a busy system. It doesn't usually take that long, but it often takes a second or two. It is a very important optimization to hold the connection. Postgres may not be as bad, but it's common for SQL systems to have slow connection times. There are databases that allow you to change the current user without reconnecting. In fact someone posted a module to do this a while back, but I can't remember which database it was for. Seems like it was Sybase or Informix. - Perrin
Re: Apache::DBI or What ?
On Fri, 2002-03-22 at 11:42, Andrew Ho wrote: Hello, EFI will have many different users, users as in database users. So am I EFjust screwed and won't be able to keep connections open? Do you mean users as in actual RDBMS level users? In other words, when you say database users you mean different username/passwords used from, say, a command-line SQL client? If your answer is yes then indeed, this is exactly the situation the Guide is talking about--you're screwed and probably shouldn't keep connections open. You'll have to incur a connect on each HTTP request. What would be ideal is if the database would allow you to change the user on the current connection. I know PostgreSQL will allow this using the command line interface psql tool (just do \connect database user), but I'm not sure if you can do this using DBI. If this was possible, then you could always connect to DBI using the same username/password so Apache::DBI gives you a cached connection, and then once you have the connection, you can change to the user you want. Does anyone know if any datbases support this sort of thing? Cees EFI am using Postgress, I am wondering how big DBs deal with this sort of EFthing. I am also wondering what the actual overhead is in starting the EFconnection and if there is anything that I could to to limit that EFwithout validating a specific user. In large DB projects where you expect high levels of concurrency I haven't heard of anybody using RDBMS-level users for authentication purposes. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Apache::DBI or What ?
Hello, CHWhat would be ideal is if the database would allow you to change the CHuser on the current connection. I know PostgreSQL will allow this using CHthe command line interface psql tool (just do \connect database CHuser), but I'm not sure if you can do this using DBI. CH CHDoes anyone know if any datbases support this sort of thing? This occurred to me in the case of Oracle (one of my co-workers was facing a very similar problem in the preliminary stages of one of his designs), and I actually had asked our DBAs about this (since the Oracle SQL*Plus also allows you to change users). As I suspected (from the similar connect terminology), our DBAs confirmed that Oracle just does a disconnect and reconnect under the hood. I would bet the psql client does the same thing. I don't have a PostgreSQL installation handy at the moment, but I seem to recall it has a statement logger similar to MySQL's... if you have it handy, you could try the \connect from psql and see if it results in a disconnect and reconnect. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Apache::DBI or What ?
We encountered just this situation when we started to move from a win32 application connecting to an RDBMS to a web based app. On the win32 app, the DB authenticated each user with a loginid/pw. Since some users still use the win32 app, we can't just abandon the DB authentication, so here's what we did: Since the web users generaly login to the site once a day and then work for awhile, (we keep the login associated to a session cookie in the DB), we run the login script as a CGI, test the loginid/passwd in a connect, store the session info, then issue a redirect. All of the other pages use Apache::DBI with a web-user DB login. This allows us take advantage of the persistent connections for most of the requests. One trick here, if you're using the DB to enforce business rules based on the login, then you'll have to encorporate those rules into your mod_perl programs -- effectively giving the web-user the power to do whatever any of the users might need to. Fortunately, we were able to do this fairly easily. I'm open to opinions on this approach. Eric Frazier wrote: Hi, I was all happy and rolling along when I read this in the docs. With this limitation in mind, there are scenarios, where the usage of Apache::DBI is depreciated. Think about a heavy loaded Web-site where every user connects to the database with a unique userid. Every server would create many database handles each of which spawning a new backend process. In a short time this would kill the web server. I will have many different users, users as in database users. So am I just screwed and won't be able to keep connections open? Or maybe the idea would be to go ahead and let that happen, but timeout the connection in 5 mintues or so? That way I wouldn't have open connectoins from user bob from 5 hours ago still siting around. Or am I totaly not getting it at all? I am using Postgress, I am wondering how big DBs deal with this sort of thing. I am also wondering what the actual overhead is in starting the connection and if there is anything that I could to to limit that without validating a specific user. Last of all, I might not be posting this to the right place, but I hope so. It seems to me there is a grey area when it comes to Apache modules when you are using them with mod_perl. Or else I just don't know enough yet to see there is not a grey area :) Thanks, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) -- Kevin Berggren 760-480-1828 System Maker, Inc 3913 Sierra Linda Dr. Escondido, CA 92025
Re: Apache::DBI or What ?
Hello, EFI will have many different users, users as in database users. So am I EFjust screwed and won't be able to keep connections open? Do you mean users as in actual RDBMS level users? In other words, when you say database users you mean different username/passwords used from, say, a command-line SQL client? If your answer is yes then indeed, this is exactly the situation the Guide is talking about--you're screwed and probably shouldn't keep connections open. You'll have to incur a connect on each HTTP request. EFI am using Postgress, I am wondering how big DBs deal with this sort of EFthing. I am also wondering what the actual overhead is in starting the EFconnection and if there is anything that I could to to limit that EFwithout validating a specific user. In large DB projects where you expect high levels of concurrency I haven't heard of anybody using RDBMS-level users for authentication purposes. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Apache::DBI startup?
On Wed, 20 Mar 2002, Stas Bekman wrote: Doug Silver wrote: I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I can have the entry like so and it seems to start fine: Apache::DBI-connect_on_init (dbi:pg(PrintError=1,AutoCommit=0):, , ) or die Cannot connect to database: $DBI::errstr; The error log shows a couple of Apache::DBI PerlChildInitHandler entries, so I think it's working, but would like to confirm it. Yes see http://perl.apache.org/guide/databases.html#Debugging_Apache_DBI Actually, that's what I had it on: [Wed Mar 20 10:45:16 2002] [notice] Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.1.0 mod_ssl/2.8.5 OpenSSL/0.9.6a configured -- resuming normal operations 30460 Apache::DBI PerlChildInitHandler 30461 Apache::DBI PerlChildInitHandler 30462 Apache::DBI PerlChildInitHandler 30463 Apache::DBI PerlChildInitHandler 30464 Apache::DBI PerlChildInitHandler [Wed Mar 20 10:45:16 2002] [notice] Accept mutex: flock (Default: flock) From my startup.pl: # choose debug output: 0 = off, 1 = quiet, 2 = chatty $Apache::DBI::DEBUG = 2; I guess I just wanted some confirmation on how the DBI was able to establish the connection without a database or username specified. Guess it's working, which is the main issue. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Re: Apache::DBI startup?
Doug Silver wrote: I don't know if this is a PostgreSQL oddity, but in the startup.pl file, I can have the entry like so and it seems to start fine: Apache::DBI-connect_on_init (dbi:pg(PrintError=1,AutoCommit=0):, , ) or die Cannot connect to database: $DBI::errstr; The error log shows a couple of Apache::DBI PerlChildInitHandler entries, so I think it's working, but would like to confirm it. Yes see http://perl.apache.org/guide/databases.html#Debugging_Apache_DBI -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Apache::DBI startup failure
I've seen similar behavior with DBD::Sybase; if your SYBASE env variable
is not set or points at an invalid directory Apache starts up but begins
segging every child process over and over again.
I'm not familiar with Postgres but this might point you in the right
direction.
On Thu, 2002-03-14 at 18:09, Doug Silver wrote:
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI::Carp ();
$Apache::DBI::DEBUG = 2;
Apache::DBI-connect_on_init
(DBI:Pg:dbname=demo;host=localhost, demo, ,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # require transactions
}
)
or die Cannot connect to database: $DBI::errstr;
1;
And here's what happens:
[Thu Mar 14 14:28:35 2002] [notice] Apache/1.3.22 (Unix) mod_perl/1.26 PHP/4.1.0
mod_ssl/2.8.5 OpenSSL/0.9.6a configured -- resuming normal operations
13336 Apache::DBI PerlChildInitHandler
13337 Apache::DBI PerlChildInitHandler
13338 Apache::DBI PerlChildInitHandler
13339 Apache::DBI PerlChildInitHandler
13340 Apache::DBI PerlChildInitHandler
[Thu Mar 14 14:28:35 2002] [notice] Accept mutex: flock (Default: flock)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13338 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13339 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13337 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:35 2002] [notice] child pid 13336 exit signal Segmentation fault
(11)
[Thu Mar 14 14:28:36 2002] [notice] child pid 13340 exit signal Segmentation fault
(11)
If I don't use the connect_on_init stuff, I can run a test script fine with those
exact db parameters.
Any suggestions?
Thanks!
--
~
Doug Silver
Network Manager
Quantified Systems, Inc
~
--
Brendan W. McAdams | [EMAIL PROTECTED]
Senior Applications Developer | (646) 375-1140
TheMuniCenter, LLC | www.themunicenter.com
Always listen to experts. They'll tell you what can't be done, and why.
Then do it.
- Robert A. Heinlein
signature.asc
Description: This is a digitally signed message part
Re: Apache::DBI startup failure
Ok, I found it, but this has got to be some kind of bug.
This works:
Apache::DBI-connect_on_init(dbi:pg:demo,demo);
This doesn't:
Apache::DBI-connect_on_init(dbi:Pg:demo,demo);
That's right, putting 'dbi:pg' in lowercase made it work. I looked through
some old newsgroup stuff and saw someone using Postgres had it similar to
that.
Here's some further debugging information for the developers:
perl -v = v5.6.1 on i386-freebsd (FreeBSD 4.4)
# pkg_info |egrep -i dbi|postgres
p5-Apache-DBI-0.88 DBI persistent connection, authentication and authorization
p5-DBD-Pg-1.01 Provides access to PostgreSQL databases through the DBI
p5-DBI-1.20 The perl5 Database Interface. Required for DBD::* modules
postgresql-7.1.3A robust, next generation, object-relational DBMS
-doug
On 14 Mar 2002, Brendan W. McAdams wrote:
I've seen similar behavior with DBD::Sybase; if your SYBASE env variable
is not set or points at an invalid directory Apache starts up but begins
segging every child process over and over again.
I'm not familiar with Postgres but this might point you in the right
direction.
On Thu, 2002-03-14 at 18:09, Doug Silver wrote:
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI::Carp ();
$Apache::DBI::DEBUG = 2;
Apache::DBI-connect_on_init
(DBI:Pg:dbname=demo;host=localhost, demo, ,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # require transactions
}
)
or die Cannot connect to database: $DBI::errstr;
1;
[Fwd: Re: Apache::DBI startup failure]
Weird, although I bet if you had straced the apache processes you would
have seen the File not found.
For some reason I recall DBD Drivers being case sensitive.
On Thu, 2002-03-14 at 20:06, Doug Silver wrote:
Ok, I found it, but this has got to be some kind of bug.
This works:
Apache::DBI-connect_on_init(dbi:pg:demo,demo);
This doesn't:
Apache::DBI-connect_on_init(dbi:Pg:demo,demo);
That's right, putting 'dbi:pg' in lowercase made it work. I looked through
some old newsgroup stuff and saw someone using Postgres had it similar to
that.
Here's some further debugging information for the developers:
perl -v = v5.6.1 on i386-freebsd (FreeBSD 4.4)
# pkg_info |egrep -i dbi|postgres
p5-Apache-DBI-0.88 DBI persistent connection, authentication and authorization
p5-DBD-Pg-1.01 Provides access to PostgreSQL databases through the DBI
p5-DBI-1.20 The perl5 Database Interface. Required for DBD::* modules
postgresql-7.1.3A robust, next generation, object-relational DBMS
-doug
On 14 Mar 2002, Brendan W. McAdams wrote:
I've seen similar behavior with DBD::Sybase; if your SYBASE env variable
is not set or points at an invalid directory Apache starts up but begins
segging every child process over and over again.
I'm not familiar with Postgres but this might point you in the right
direction.
On Thu, 2002-03-14 at 18:09, Doug Silver wrote:
I can't seem to get Apache::DBI to start up properly.
Here's my startup.pl:
#!/usr/bin/perl -w
use strict;
use Apache ();
use Apache::Status ();
use Apache::DBI (); # This *must* come before all other DBI
modules!
use Apache::Registry;
use CGI ();
CGI-compile(':all');
use CGI::Carp ();
$Apache::DBI::DEBUG = 2;
Apache::DBI-connect_on_init
(DBI:Pg:dbname=demo;host=localhost, demo, ,
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # require transactions
}
)
or die Cannot connect to database: $DBI::errstr;
1;
--
Brendan W. McAdams | [EMAIL PROTECTED]
Senior Applications Developer | (646) 375-1140
TheMuniCenter, LLC | www.themunicenter.com
Always listen to experts. They'll tell you what can't be done, and why.
Then do it.
- Robert A. Heinlein
--
Brendan W. McAdams | [EMAIL PROTECTED]
Senior Applications Developer | (646) 375-1140
TheMuniCenter, LLC | www.themunicenter.com
Always listen to experts. They'll tell you what can't be done, and why.
Then do it.
- Robert A. Heinlein
signature.asc
Description: This is a digitally signed message part
Re: Apache::DBI
Marty == Marty J Rogers [EMAIL PROTECTED] writes: Marty I had tried that, with the same result. (does Apache::DBI Marty overload the DBI methods?) Full error is as follows. Again, Marty any help is _highly_ appreciated. You must specify the full package name to the connect_on_it sub, as in Apache::DBI-connect_on_init(...) Peace.
Re: Apache::DBI
I had tried that, with the same result. (does
Apache::DBI overload the DBI methods?) Full
error is as follows. Again, any help is _highly_
appreciated.
Marty
[error] Can't locate object method connect_on_init via package Apache::DBI at
/etc/httpd/conf/startup.pl line 28.
Compilation failed in require at (eval 14) line 1.
Syntax error on line 1276 of /usr/local/apache/conf/httpd.conf:
Can't locate object method connect_on_init via package Apache::DBI at
/etc/httpd/conf/startup.pl line 28.
Compilation failed in require at (eval 14) line 1.
--
On Tue, 12 Feb 2002 08:44:12 Martin Haase-Thomas wrote:
Marty J. Rogers wrote:
[snip]
From httpd.conf:
PerlModule Apache::DBI CGI DBD::mysql \
Apache::AuthenDBI
PerlRequire /path/to/startup.pl
Alias /perl/ /path/to/perl
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
/Location
and from startup.pl:
use DBI();
use Apache::DBI(); # !! :)
use DBD::mysql();
.
.
.
DBI-connect_on_init(DBI:mysql:dbname,
user,pass,
{Options here}
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
Re: Apache::DBI
(doesApache::DBI overload the DBI methods?)
No, it doesn't. It uses Apache and DBI. Did you install the package via the
"Makefile.PL" stanza? Maybe you should just install it another time. On the
other hand, Apache::DBI doesn't export anything. Try calling it with the
package name explicitly.
kind regards
Martin
Marty J. Rogers wrote:
[EMAIL PROTECTED]">
I had tried that, with the same result. (doesApache::DBI overload the DBI methods?) Fullerror is as follows. Again, any help is _highly_appreciated.Marty[error] Can't locate object method "connect_on_init" via package "Apache::DBI" at /etc/httpd/conf/startup.pl line 28.Compilation failed in require at (eval 14) line 1.Syntax error on line 1276 of /usr/local/apache/conf/httpd.conf:Can't locate object method "connect_on_init" via package "Apache::DBI" at /etc/httpd/conf/startup.pl line 28.Compilation failed in require at (eval 14) line 1.--On Tue, 12 Feb 2002 08:44:12 Martin Haase-Thomas wrote:
Marty J. Rogers wrote:
[snip]From httpd.conf:PerlModule Apache::DBI CGI DBD::mysql \Apache::AuthenDBIPerlRequire /path/to/startup.plAlias /perl/ /path/to/perlPerlModule Apache::RegistryLocation /perlSetHandler perl-scriptPerlHandler Apache::RegistryOptions ExecCGIallow from allPerlSendHeader On/Locationand from startup.pl:use DBI();
use Apache::DBI(); # !! :)
use DBD::mysql();...DBI-connect_on_init("DBI:mysql:dbname", "user","pass", {Options here}Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com
Re: Apache::DBI
Marty J. Rogers wrote:
[snip]
From httpd.conf:
PerlModule Apache::DBI CGI DBD::mysql \
Apache::AuthenDBI
PerlRequire /path/to/startup.pl
Alias /perl/ /path/to/perl
PerlModule Apache::Registry
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
PerlSendHeader On
/Location
and from startup.pl:
use DBI();
use Apache::DBI(); # !! :)
use DBD::mysql();
.
.
.
DBI-connect_on_init(DBI:mysql:dbname,
user,pass,
{Options here}
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at
http://www.eudoramail.com
Re: Apache::DBI
Stathy G. Touloumis wrote: I thought I saw a posting on how to retrieve an independent database handle from Apache::DBI using a certain method call (instead of from the shared $dbh for the child). Does anyone know where this documentation may reside (If it is possible). I'm not sure what you mean, really, but perhaps you mean dbi_connect_method? from man DBI: The dbi_connect_method attribute can be used to specify which driver method should be called to establish the connection. The only useful values are 'connect', 'connect_cached', or some specialized case like 'Apache::DBI::connect' (which is automatically the default when running within Apache). so, basically you can create a connection under Apache::DBI that is _not_ cached using 'connect'. is that what you meant? --Geoff
