Re: mod_perl guide HELP -- Full transcript
[Moving the discussion where it belongs to: the mod_perl list] On Fri, 3 Aug 2001, christopher sagayam wrote: > please ignore if my earlier email was clear enough what's the value of PERL and FULLPERL var in the generated Makefile? e.g. on my machine: PERL = /usr/bin/perl FULLPERL = /usr/bin/perl if it's not /tmp/chrisperl/bin/perl than you have an issue with Perl, and not mod_perl. > # /tmp/chrisperl/bin/perl Makefile.PL > Configure mod_perl with ../apache_1.3.20/src ? [y] y > Shall I build httpd in ../apache_1.3.20/src for you? [y] y > Appending mod_perl to src/Configuration > Using config file: /tmp/dump/mod_perl-1.26/src/Configuration > Creating Makefile > + configured for Solaris 280 platform > + setting C compiler to gcc > + setting C pre-processor to gcc -E > + checking for system header files > + adding selected modules > o perl_module uses ConfigStart/End > + mod_perl build type: OBJ > + setting up mod_perl build environment > + id: mod_perl/1.26 > + id: Perl/5.00503 (solaris) [perl] > > chris > > - Original Message - > From: "christopher sagayam" <[EMAIL PROTECTED]> > To: "Stas Bekman" <[EMAIL PROTECTED]> > Sent: Friday, August 03, 2001 11:19 AM > Subject: Re: mod_perl guide HELP > > > > Thanks a lot for your response > > > > but what happens is when it reports > > > > + adding selected modules > > o perl_module uses ConfigStart/End > > + mod_perl build type: OBJ > > + setting up mod_perl build environment > > + id: mod_perl/1.26 > > + id: Perl/5.00503 (solaris) [perl] > > > > it reports the old version namely 5.00503 > > > > whereas the new perl is version > 5.6 > > > > # /tmp/chrisperl/bin/perl -v > > > > This is perl, v5.6.1 built for sun4-solaris > > > > Copyright 1987-2001, Larry Wall > > > > Perl may be copied only under the terms of either the Artistic License or > > the > > GNU General Public License, which may be found in the Perl 5 source kit. > > > > Complete documentation for Perl, including FAQ lists, should be found on > > this system using `man perl' or `perldoc perl'. If you have access to the > > Internet, point your browser at http://www.perl.com/, the Perl Home Page. > > > > please help again ? > > > > Thanks > > > > chris > > > > > > > > - Original Message - > > From: "Stas Bekman" <[EMAIL PROTECTED]> > > To: "christopher sagayam" <[EMAIL PROTECTED]> > > Sent: Friday, August 03, 2001 11:09 AM > > Subject: Re: mod_perl guide HELP > > > > > > > yOn Fri, 3 Aug 2001, christopher sagayam wrote: > > > > > > > I want the modperl and apache installation to recognize the perl > > installed at > > > > > > > > /tmp/newperl/bin/perl and not the default /usr/bin/perl > > > > > > > > so what configuration parameteres i must pass to perl Makefile.PL > > > > > > You should build mod_perl with your other Perl > > > > > > % /tmp/newperl/bin/perl Makefile.PL ... > > > > > > > > > _ > > > Stas Bekman JAm_pH -- Just Another mod_perl Hacker > > > http://stason.org/ mod_perl Guide http://perl.apache.org/guide > > > mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ > > > http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ > > > > > > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
odd behavior with Cache::Cache
i'm observing some behavior using Cache::Cache that seems odd, altho it may be due to my faulty understanding of how the interface works. i'm using Cache::MemoryCache to manage a cache of session objects in a non-forking apache process. once i've initially called set to store a session object using its session id as the key, i then call get a couple of times per request to get the session object out of the cache. problem is, each time i call get, i'm apparently getting a different instance of the session class! furthermore, each instance's variables are the values that were originally set at creation time, regardless of whether i update the variables during later requests or not. here's a snippet of my debug output for two subsequence requests: # first request. the server has just started, so there are # no cached sessions (the requested session id refers to an # invalid session). we create a new session (with a new id), # set it in the cache, then get it back out for later use. # notice the final get call seems to return a different # instance than the set call! get session for id [39a0a4ce81943263b25474c20b087586]: get session for id [39a0a4ce81943263b25474c20b087586]: get session for id [b2ac8e8d51f4512c4bcf8476126f54a5]: set session for id [b2ac8e8d51f4512c4bcf8476126f54a5]: Wombat::Core::Session=ARRAY(0x886a838) get session for id [b2ac8e8d51f4512c4bcf8476126f54a5]: Wombat::Core::Session=ARRAY(0x88863bc) # second request. each get call is finding /something/ for # the given key, but again it seems to be a different # instance each time! get session for id [b2ac8e8d51f4512c4bcf8476126f54a5]: Wombat::Core::Session=ARRAY(0x88bc8f4) get session for id [b2ac8e8d51f4512c4bcf8476126f54a5]: Wombat::Core::Session=ARRAY(0x88c06dc) i see this behavior regardless of whether i'm using Cache::MemoryCache with a non-forking apache or Cache::SharedMemoryCache with a forking apache. so i feel that either i'm doing something wrong in my usage of the Cache::Cache interface, or i'm overlooking some obvious perl behavior. any idea what might be going wrong?
RE: Apache::DBI in startup.pl generating error
Rob, how much stuff do you have in startup.pl? So nothing else is dependent
on Apache.pm modules?
To some degree, because Apache::DBI affects all the Perl interpreters in a
very config-type of way (as opposed to just preloading modules) I like the
idea of it being in PerlModule as it allows some servers to have caching
off and some servers to have it on yet still keep the application level
startup code in startup.pl.
I guess I've always considered startup.pl to be a place for dealing with
the various applications you are using and optimizing them by precaching
selected modules because you really need to use Perl code if you want to do
anything half way complex such as importing namespaces or creating global
singletons in a particular package space.
Whereas, something simple like Apache::DBI which turns on and off caching
seems just as well in PerlModule.
However, I also think that this is unworthy of inclusion into the guide.
PerlModule is well documented. startup.pl is well documented. Documenting
where to put Apache::DBI? That's up to the sysadmin. Doesn't seem worthy of
guide inclusion.
For the complaint about $ENV{MOD_PERL}. I am not quite sure I really agree
that this is a bad thing. Basically, by design you can see in your code
explicitly which code will be run when Mod_perl is running and which code
will not. What's so bad about that?
However, if you really have a problem with this, why don't you create
startup.pl and then a second non-apache-depdenent-startup.pl which is
require'd from startup.pl
Then when you run your script from the command line, just test the
non-apache-dependent-startup.pl being loaded first so that startup.pl only
contains mod_perl specific config. That way you get the best of both worlds.
You could also probably do a check on $INC{'Apache.pm'} or something like
that if you wanted to be a real stickler because in theory it might be
possible to bootstrap a pseudo Apache.pm for non-inside-Apache testing.
Anyway, in all these cases it does seem like there is more than one way to
do it, and advocating a specific way just doesn't seem right for the guide
since I think it is arguable either way.
Later,
Gunther
At 06:17 PM 8/2/2001 -0700, Rob Bloodgood wrote:
> > only if you code it the way you did below, which isn't terribly portable.
> > see http://perl.apache.org/guide/perl.html#use_require_do_INC_and
>
>Ahem, PerlModule is a wrapper around the perl builtin require(). One
>presumes that perl knows where it lives if perl can successfully require()
>it. Especially since this module is installed into the standard perl
>heirarchy as a system module, from CPAN. It's not even XS.
>
> > basically, it's a bad programming practice not to use() modules in the
>code
> > that needs them. it works if you call PerlModule before you use() the
> > module, but again, it requires you to pay better attention to your
> > httpd.conf than you ought to.
>
>See my above point. Apache::DBI is *made* to be transparent, or at least
>semi-. It exists at the server level, and without (much) interaction with
>the programmer's dataspace at all. What better place for it than
>httpd.conf? And as for having to pay too much attention... well... let's
>just say that RedCode is spreading like it is because not enough IIS Admins
>"paid better attention" to the defaults THEY were given. :-) Seriously tho,
>why WOULDN'T you know what exactly is in your server configuration?
>
> > consider writing an Apache module for CPAN, relying on, say, Apache::Log
> > calls, but failing to use Apache::Log in your module. If you have a
> > PerlModule Apache::Log everything works - until somebody else tries to run
> > your code with a different configuration. There's what works and then
> > there's how you ought to do things.
>
>Again, server-level and mostly transparent. And as far as requiring a
>module, 1) I would expect it to be clearly documented 2) and if I didn't
>read the dox I deserve to have wasted the time, and 3) I'll leave 3 for
>below...
>
> > >methods on it are valid, and can be easily wrapped as I suggested
> > >in an "if($ENV{MOD_PERL}) {}" block.
> >
> > this is just a particular gripe of mine, but I think we ought to be
> > past the $ENV{MOD_PERL} thing by now... startup.pl is a mod_perl
> > idiom. if you are designing web applications that depend on things
> > like the mod_perl API, Apache::DBI, and using the hooks into the
> > Apache request cycle then you are already way beyond making a
> > startup.pl script portable between mod_perl and other web
> > environments.
>
>Portable, portable, portable... First of all, understanding that items
>appearing earlier or later in a config file is significant is so common I'm
>astonished you consider it bad manners to see code that depends on it. And
>unless I'm very badly mistaken, it's even significant in httpd.conf as far
>as *Apache* is concerned.
>
>And secondly, you're right, this is *mod_perl*. Not IIS, NSAPI, PHP
RE: Apache::DBI in startup.pl generating error
> Alternatively, you can remove
>
> use Apache;
>
> from Apache::DBI and then you can test it perflectly fine from the
> command-line, you just won't be able to use connect_on_init()
> which is the
> only reason Apache::DBI seems to load Apache.pm (Apache.pm is
> causing your
> problem not Apache::DBI).
>
> >It's not a problem. Apache::DBI expects mod_perl env, and hence you
cannot
> >test it from the command line. I suppose that you don't have a problem to
> >start the server with Apache::DBI loaded.
> >
> >It's documented somewhere is the guide too.
Well, it should be documented "somewhere in the guide", or presumable in
Apache::DBI.pod, that one should *only*
PerlModule Apache::DBI
Since it's pointless in startup.pl (right?).
Then a block like:
if ($im_in_mod_perl_now) {
$Apache::DBI::parameter = $newvalue;
# etc
}
would be completely appropriate in startup.pl.
My $.02
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Re: Just while we are so nicely [OT]: SQL Search Results in pages
At 1:07 PM +0200 8/2/01, Joachim Zobel wrote: >Hi. > >One of the really nice features of MySQL (OK, its not a "real" >RDBMS, but who cares:) is LIMIT. > >Using Oracle I have found it a real pain to display search results >in pages (of eg 20) while using connection pooling. The problem is >that you can not be shure to repeat the same resultset on every >page. This gets a real problem if the queries get expensive and I >can't afford sorting because it destroys first row performance. You can with a result index. When your user first gets to the page, dump the rowids and rownums to a result_index table. create table result_index ( session_idnumber(10), myrowid varchar(30), myrownum number(10), mydatedate ); insert into result_index select 123456,rowid,rownum,sysdate from your_table; The date column is so that you can purge the result index after 24 hours... delete from result_index where mydate < sysdate - 1; Then, for the query... select * from result_index a, your_table b where a.session_id = ? and a.myrowid = b.rowid and a.myrownum between ? and ? I have not actually implemented this anywhere. I wrote something similar where I limited based on rownum, but rownum only numbers the result set, not the table set. Rob >Is there a generic soloution to this? Has anybody found this worth >writing a pattern? > >Thanx, >Joachim >-- >"... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden >koennen."- Bertolt Brecht - Leben des Galilei -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: From cgi-lib.pl to CGI.pm Upload conversion!?
On Fri, 3 Aug 2001, John Buwa wrote:
> Hello,
>
> I am trying to finish up my conversion from cgi-lib.pl to CGI.pm using the cgilib
>mode in CGI.pm. The cgilib emulation mode does not provide the normal cgilib file
>upload calls. I looked at the guide on using the file upload feature, but it does not
>tell you how to use it?
>
> in my cgilib script i am converting, this is the proccessing part of the script and
>not the prior html:
>
> $cgi_lib'maxdata = 11;
> $cgi_lib'writefiles = '/path/i/want/the/file/located/in;
> $cgi_lib'filepre = 'ad'; #added the begining of all file names i.e. adsomefile
> &ReadParse(*input); $the cgilib readparse call
> print &PrintHeader;
> print &HtmlTop("File Upload Results");
> print "some html here saying the file was uploaded click to continue";
> 1;
>
> The above is the upload script in a nutshell called but the previos
> form to proccess this. Now how in CGI.pm do you convert this. I looked
> at http://stein.cshl.org/WWW/software/CGI/#upload_caveats but wasnt
> any help.
Now what this has to do with mod_perl?
The feature is not there, I'm sure Lincoln will accept a patch to handle
the file uploads, but again this is a wrong forum.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
OT: building a server -- advise needed
I have been tasked with re-designing our Sun Server. As it sits right now, it's basically hosed it's a conglomeration of patches, bailing twine, duct tape and whatnot. We are running a Sun Ultra10 with an Ultra SCSI array, Solaris 2.6 the latest Apache, Perl, and JDK. We have installed ModPerl 1.2.5 and various and sundry packages and libraries. Whet I am planning to do is wipe out the drives and start with a fresh install of the OS. It looks as if we will be going with Solaris 8 What I am looking for is advise and recommendations for: Configurations for this server (Sun, Ultra 10, Solaris8 [what else]) New Server (Make, Model, OS, etc) Any other advice you can recommend Thanks in advance for your help. Paul
Help needed. LWP-5.48 dicovered..
Hi All, I know all of you are very busy, but could you look at POST request results ( this is "print $req->as_string ") : What is the "%00H" in the last line??? my $resp = $ua->request(POST 'https://www.assist.ru/reports/results.cfm', [ @params ]); my $req = $resp->request; print $req->as_string [ debug | Thu Aug 2 03:50:02 2001 ] POST http://bsadm.yyy.com/banners.xhtml User-Agent: libwww-perl/5.48 Content-Length: 3103 Content-Type: application/x-www-form-urlencoded orderid1=299&bannerid1=56&title1=AMT%26amp%3BC%20Ltd.&body1=%F0%CF%CC%C9%CD% C5%D2%CE%D9%C5%0D%0A%CD%C1%C7%CE%C9%D4%CE% [..] %0D%0A%EB%CF%CE%D3%D5%CC%D8%D4%C1%C3%C9%C9&href1=http%3A%2F%2Famtc.org%2Frus %2FSales.html&phrases1=%CD%C1%C7%CE%A9%00% [.. look at %00] [.. skipped a lot ] %CC%CB%C1%20-%D4%CF%CD%CF%E2%00%00%00H%FC%20- What is the %00H ??? How could it happend??? Is it LWP bug? phrases1 does not contain 'H' chars .. Vlad.
[Fwd: Help with @ISA]
Hello there,
I have a problem and I am not sure how to explain it... So please
forgive me if I sound like a rookie, since I am that.
I have a packge called: my::foo in which I have declared the following:
package my::foo;
@my::foo::ISA = qw( my::bar );
.
.
.
sub handler
{
my $r = shift;
.
.
# rest of the code
}
I have a method called cookie_check in my 'my::bar' package that needs
to be called before my controller or 'my::foo' takes over.
package my::bar;
sub cookie_check
{
my $self= shift;
.
.
.
# rest of the code
}
I have declared the following in my httpd.conf:
SetHandler perl-script
PerlHandler my::foo->cookie_check()
However, I get an error message:
Can't locate object method "cookie_check()" via package my::foo
Can anyone tell me what am I doing wrong?
Thanks in advance
-r
modules/status make test fail
I can come back with more, if needed, but just in case someone else has seen this: Fresh 1.26 and 1.3.20 Sun Solaris 2.6 Perl 5.005_03 I just did this on Linux and it worked just fine :( This doesn't bother me, too much modules/request.Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 147. Use of uninitialized value at modules/request.t line 149. skipping test on this platform modules/src.ok modules/ssi.ok modules/stage...skipping test on this platform But: modules/status..Internal Server Error dubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 8-10 Failed 3/10 tests, 70.00% okay In error_log: [Fri Aug 3 16:27:16 2001] [error] Can't locate object method "inh_tree" via package "Devel::Symdump" at /data/_g/lii/apache/1.26/mod_perl-1.26/blib/lib/Apache/Status.pm line 222, chunk 1. Do I need an updated Devel::Symdump? Bill Moseley mailto:[EMAIL PROTECTED]
Re: segfault with mod_perl, Oraperl, XML::Parser
On 03 Aug 2001 10:26:37 -0700, Scott Kister wrote: > Thanks everyone for their help, I tried all the suggestions with no > luck, and I definitely configured Apache without expat. I finally > ended up parsing the XML in perl instead of using Expat. Since I > already had handlers, it was quite easy, although still needs better > validation and error handling. Try XML::LibXML. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: dbi abstraction layer on perlmonks
On Thursday, August 2, 2001, at 03:00 PM, Robert Landrum wrote: > Sweet... > > I was getting kinda tired of my Linux box "going down on me." You must be thinking Windows! -- -- Tom Mornini -- ICQ 113526784
Apache::URI problems
I'm seeing this problem both under mod_perl 1.25 and 1.26. I've installed mod_perl as a DSO outside of the Apache source tree using APXS. It seems to work fine, except for Apache::URI. Here's my test script: #!/usr/bin/perl use strict; use Apache::FakeRequest; use Apache::URI; my $req = Apache::FakeRequest->new( 'get_server_name' => 'dev1.aus1.datafoundry.net' ); my $uri = Apache::URI->parse( $req, 'main/test.html' ); print 'URI: ', $uri->unparse(), "\n"; print 'SCHM: ', $uri->scheme(), "\n"; print 'PATH: ', $uri->path(), "\n"; print 'RPTH: ', $uri->rpath(), "\n"; All I'm doing is some simple testing. The problem is, I'm getting this error: Can't locate object method "parse" via package "Apache::URI" (perhaps you forgot to load "Apache::URI"?) at t1 line 10. Looking at an old install of both perl and mod_perl (which are both not being used or considered), I see that there are actually three related URI files: /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/Apache/URI.pm /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/auto/Apache/URI/URI.bs /usr/local/lib/perl5/site_perl/5.6.0/i86pc-solaris/auto/Apache/URI/URI.so Under the version of perl I'm actually working with, though, only the first exists /usr/local/lib/perl5/site_perl/5.6.1/i86pc-solaris/Apache/URI.pm How come the rest of the code for URI isn't being installed? Did something change at 1.25 to make it unnecessary? Am I doing something wrong? Does parse() not exist as a class method anymore (if so, the docs are out of date)? The perl being used has this configured for @INC: Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under solaris Compiled at May 14 2001 09:09:43 @INC: /usr/local/lib/perl5/5.6.1/i86pc-solaris /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i86pc-solaris /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl . Thanks in advance for any assistance, Philip * Philip Molter * Texas.net Internet * http://www.texas.net/ * [EMAIL PROTECTED]
Re: segfault with mod_perl, Oraperl, XML::Parser
Thanks everyone for their help, I tried all the suggestions with no
luck, and I definitely configured Apache without expat. I finally
ended up parsing the XML in perl instead of using Expat. Since I
already had handlers, it was quite easy, although still needs better
validation and error handling.
When I get a chance I'll see if this works on mod_perl 2.0. If anyone
does get this to work on Solaris 2.8 x86, please let me know.
Thanks, Scott
#!./perl
use DBD::Oracle;
use XML::Parser::Expat;
my $parser = new XML::Parser::Expat;
$parser->parse(' here we go ');
# perl-5.6.1
# mod_perl-1.26
# apache 1.3.20
# expat-1.95.1
# DBD-Oracle-1.06
# DBI-1.15
# XML-Parser-2.30
# config_args='-Dcc=gcc -Ubincompat5005 -Uuselargefiles -Uusemymalloc -des'
On Tue, July 31 16:37 +0100, Tim Bunce wrote:
> On Mon, Jul 30, 2001 at 03:30:48PM -0400, Philip Mak wrote:
> > On Mon, 30 Jul 2001, Scott Kister wrote:
> >
> > > uselargefiles=define
> >
> > Have you tried turning off "uselargefiles"?
> >
> > I might be off track here, but recently I tried to install mod_perl on
> > Solaris 5.8. It kept segfaulting until I turned off "uselargefiles" and
> > binary compatibility with 5.00503. You could try recompiling perl with
> > this configure line, then recompiling mod_perl and see what happens:
> >
> > sh Configure -des -Dcc=gcc -Ubincompat5005 -Uuselargefiles
>
> And -Uusemymalloc
>
> (or something like that) to get perl to use the system's own malloc.
>
> Tim.
Re: dbi abstraction layer on perlmonks
Robert Landrum wrote: > The guide is a great thing, and removing items from it is risky. Think of it as refactoring.
Re: dbi abstraction layer on perlmonks
Stas Bekman wrote: >>>Maybe the guide should include links to the most mature peristence >>>abstraction layer projects out there: >>>- Class::DBI >>>- Alzabo >>>- Tangram >>>- SPOPS >>> > >I suppose that could fit into the help.pod. Otherwise it's not directly >related to mod_perl, and the guide has to start shrinking rather than >growing. > That's fine. The guide has become sort of a catch-all for web site building techniques, and maybe that should be changed in the interest of the maintainer's sanity. >I'd also start working on the new docs for mod_perl 2.0, so I can see an >extended chapter on databases and persistence layers in the users guide. > I vote to cover only the mod_perl specific stuff in there, as you said above. >Perrin, would you like to be the database chapter pumpkin? > Possibly. We should talk more about what would go into that chapter when you start working on the new guide. - Perrin
Re: Apache::Reload : eval { require $filename }
On Thu, 2 Aug 2001, Sidharth Malhotra wrote: > In the Apache::Reload module, if the 'require' fails, your script bails out, > and your client gets status 500. The side effect is that totally unrelated > scripts can fail because a bad programmer on another end of the system > forgot my a variable. > > My proposed solution is to put the require inside an eval. Upon failure, > simply write to the error log. > > My Question: If the require is in an eval, what happens when a reload > fails? Does the old code in memory stay or or is it removed w/out being > replaced by the updated code? Apache::Reload shouldn't be used on production systems. At least in the way you describe. This dissolves the problem. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: Apache::DBI in startup.pl generating error
> -Original Message- > From: Rob Bloodgood [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 02, 2001 9:18 PM > To: Geoffrey Young > Cc: mod_perl > Subject: RE: Apache::DBI in startup.pl generating error > > basically, it's a bad programming practice not to use() > modules in the > code > > that needs them. it works if you call PerlModule before > you use() the > > module, but again, it requires you to pay better attention to your > > httpd.conf than you ought to. > > See my above point. Apache::DBI is *made* to be transparent, > or at least > semi-. It exists at the server level, and without (much) > interaction with > the programmer's dataspace at all. What better place for it than > httpd.conf? And as for having to pay too much attention... > well... let's > just say that RedCode is spreading like it is because not > enough IIS Admins > "paid better attention" to the defaults THEY were given. :-) > Seriously tho, > why WOULDN'T you know what exactly is in your server configuration? well, I was going to leave this thread alone now, but I feel the need to justify myself on this one issue - I wrote that email a bit bleery-eyed... of course you need to know what your config contains. what I meant was that relying on the PerlModule syntax to allow you to call Apache::DBI->connect_on_init from your startup.pl was less than solid coding - it's the same as not use()ing modules from the scripts that require them (you didn't get that thought from what I wrote? I can't imagine why ;). as for the rest of Apache::DBI you're right, it's transparent so it doesn't matter where you load it - as long as you understand the action-at-a-distance concept, and are comfortable with it, you're ok... anyway, nuff said. Gunther and Ken tied things up nicely. --Geoff
Re: Not embedding SQL in perl (was RE: [OT] Inspired by closing comments from the UBB thread.)
[EMAIL PROTECTED] (Jeffrey W. Baker) wrote: >I've worked with Scott Ambler, and I could record everything Scott Ambler >knows about actually devleloping large systems on the head of a pin, using >a magic marker. That guy is a hopeless academic without the slightest >clue of how to actually make software happen. Don't hold back Jeff, tell us how you really feel. =) I know I've worked with some people who I'd want to say the same thing about, but so far nobody's posted any of their treatises on the list. I find this thread kind of interesting, because it's really about how different people have solved complicated problems. It's clear that some of the disagreement happens because people haven't adequately experimented with the various approaches (who has time for that, anyway?), but undoubtedly some of the disagreement happens because people genuinely have very different problems to solve. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Just while we are so nicely [OT]: SQL Search Results in pages
On Thursday, August 2, 2001, at 04:07 AM, Joachim Zobel wrote: > One of the really nice features of MySQL (OK, its not a "real" RDBMS, > but who cares:) is LIMIT. > > Using Oracle I have found it a real pain to display search results in > pages (of eg 20) while using connection pooling. The problem is that > you can not be shure to repeat the same resultset on every page. This > gets a real problem if the queries get expensive and I can't afford > sorting because it destroys first row performance. > > Is there a generic soloution to this? Has anybody found this worth > writing a pattern? Sure! Just store the results in your session, and display from there... -- -- Tom Mornini -- ICQ 113526784
Re: dbi abstraction layer on perlmonks
On Thu, Aug 02, 2001 at 02:32:01PM -0700, brian moseley wrote: > > for the next perl conference i'm writing a do everything > abstraction layer. it will provide a do_stuff routine that > will, out of the box, do your laundry and perform oral sex. > scalable, robust, state of the art technology for > e-businesses. Sounds great! But skip the oral sex, ok? I don't know where you've been. Cheers, -- Alastair| [EMAIL PROTECTED] | http://www.calliope.demon.co.uk |PGP Key : A9DE69F8 ---
Re: Just while we are so nicely [OT]: SQL Search Results in pages
On Thu, Aug 02, 2001 at 07:10:49PM +0300, raptor wrote:
> > This may be of interest:
> >
> > http://search.cpan.org/doc/TIMB/DBI_Talk5_2001/sld059.htm
>
> ]- Where is $h->{FetchHashKeyName}, I didn't found it even in the source
> perl -m DBI my version is 1.18
Umm, let's see... that talk was given just a couple of weeks ago,
the title of the slide that refers to FetchHashKeyName is "What's
Planned", and you're using a version released two months ago...
As it happens, I made of release of the DBI just before the conference
and that release, 1.19, does include $h->{FetchHashKeyName}.
Tim.
Re: dbi abstraction layer on perlmonks
On 02 Aug 2001 14:32:01 -0700, brian moseley wrote: > > for the next perl conference i'm writing a do everything > abstraction layer. it will provide a do_stuff routine that > will, out of the box, do your laundry and perform oral sex. > scalable, robust, state of the art technology for > e-businesses. Ah, the mythical ellipses operator ... :-) "yada yada yada" -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
RE: Apache::DBI in startup.pl generating error
>Except that (and I have to check this to be ABSOLUTELY shure but)
>PerlModule
>Apache::DBI happens first, THEN startup.pl.
only if you code it the way you did below, which isn't terribly portable.
see http://perl.apache.org/guide/perl.html#use_require_do_INC_and
basically, it's a bad programming practice not to use() modules in the code
that needs them. it works if you call PerlModule before you use() the
module, but again, it requires you to pay better attention to your
httpd.conf than you ought to.
consider writing an Apache module for CPAN, relying on, say, Apache::Log
calls, but failing to use Apache::Log in your module. If you have a
PerlModule Apache::Log everything works - until somebody else tries to run
your code with a different configuration. There's what works and then
there's how you ought to do things.
>
>I just checked, and it works exactly that way when the httpd.conf
>directives
>are in the following order:
>
>PerlModule Apache::DBI
>PerlRequire/etc/httpd/perl/lib/startup.pl
>
>Since Apache::DBI is now loaded into the (single) perl interpreter's
>symbol
>table, and since the above call to connect_on_init() is a method call
>(vs an
>exported symbol), calling methods on it are valid, and can be easily
>wrapped
>as I suggested in an "if($ENV{MOD_PERL}) {}" block. Explicitly, it is
>*NOT*
>required to 'use Apache::DBI ();' in startup.pl to do this.
this is just a particular gripe of mine, but I think we ought to be past the
$ENV{MOD_PERL} thing by now... startup.pl is a mod_perl idiom. if you are
designing web applications that depend on things like the mod_perl API,
Apache::DBI, and using the hooks into the Apache request cycle then you are
already way beyond making a startup.pl script portable between mod_perl and
other web environments.
--Geoff
Re: Just while we are so nicely [OT]: SQL Search Results in pages
On Thu, 2 Aug 2001, Perrin Harkins wrote: > I've had great success with "Select and cache only the row keys, fetch full > rows as needed". We were also caching the individual records (in > BerkeleyDB), so some pages never needed to hit Oracle at all after the > initial query. A good way to go, if your data is not too volatile. This is more or less how Alzabo works (but you can tweak it). When it fetches row objects, its really just fetching primary keys that match your query. As you request other columns they are fetched and cached. You can also specify some columns to be fetched with the primary key and specify that others should be considered a group (when A is fetched, get B & C too). Actually, I stole a lot of this from Michael Schwern's Class::DBI and got some more ideas from your talk at ApacheCon, Perrin. So if people are interested in implementing this, they may want to just consider using Alazbo (or you can rip out the caching code and use that separately if you want). -dave /*== www.urth.org We await the New Sun ==*/
