RE: Exception modules
From: Paul Lindner, on Tuesday, May 01, 2001 3:04 AM: On a related note, does anyone anywhere still use Experimental::Exception? The COPE CORBA module uses Experimental::Exception for it's exception handling. There is an effort underway to change to Error.pm (or something else a bit more standardized) but I don't know how far that is. Henrik Tougaard, FOA, Denmark.
RE: ORBs
Matt Sergeant writes: CORBA::ORBit is very simple to use. I'd be very interested in hearing from anyone who has used this in a mod_perl project. We are currently using CORBA and mod_perl for scaleable access to databases. The setup is: Web-server: Apache::ASP and client-side COPE. App-server: COPE and DBI. We use COPE instead of CORBA::ORBit, as COPE runs just nicely on Digital Unix (which we use) and ORBit is a hassle to port. There are some not-to-nice mismatches here and there, especially in the errorhandling - COPE, DBI and Apache::ASP use 3 different strategies and it cvan be quite cumbersome to get things running smoothly -not impossible though. We hope to gain: - better scaleability: we can add more servers whenever a bottelneck appears, - better security: the acces to the database is guarded by the app-servers (who validate user access etc), - better modularity: the ASP-coders are mainly concered with appearance and user-dialog, the app-servers handle the buisness logic. Until now it seems to hold true. -- Henrik Tougaard, [EMAIL PROTECTED] Forbundet af Offentligt Ansatte, Copenhagen, Denmark.
RE: RFC: DBI::Prof
From: Perrin Harkins [mailto:[EMAIL PROTECTED]] On Tue, 28 Nov 2000, Stas Bekman wrote: And fetch()es are quite irrelevant for performance improvements since they never change unless you compare TCP/IP vs UNIX sockets or one driver against the other. I find the fetch information useful when deciding whether to do a more complex query that retrieves fewer results or a simple one that retrieves extra data and then sift through it in perl. For some drivers (DBD::Ingres for one) the $sth-execute only optimizes the query, the data is fetched in the first call to fetch. Fetching the first row does all the "real" work, joining and sorting etc. So you will se a very fast prepare time, a not-too-long execute time, and (in some cases) a horribly long fetch-time for the first fetch. -- Henrik Tougaard, [EMAIL PROTECTED] DBD::Ingres maintainer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: compiling modperl on alpha
From: Didier Godefroy [mailto:[EMAIL PROTECTED]] [...snip...] But in any case, trying to use perl 5.6 is nothing but trouble and if someone has been able to make all this work with it, I'd like to know how! We have a Perl5.6.0 with apache 1.3.14 and mod_perl 1.24_01 built with no problems. Did it just according to the book (which one? Don't know :) perl Makefile.PL EVERYTHING=1 PERL_TRACE=1 and them build httpd in the apache tree. Works just fine. I have tried building with DSO, but that fails miserably. Did so with perl5.005_03 as well. Just my EUR0.02. Henrik Tougaard, FOA, Denmark. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: need AuthName error
From: Victor Michael Blancas [mailto:[EMAIL PROTECTED]] Has anybody experienced something like this in their error log [(date)] [error] [client (client's ip)] need AuthName: (filename) But the pages are served without errors. Using mod_perl 1.24_01 on Apache 1.3.14 Apache::ASP Yep. Same "problem" here. I've been tearing my hair out trying to figure where that error message is coming from No problems with Apache/1.3.12 and nod_perl/1.23 Henrik Tougaard, FOA, Denmark.
RE: Bug in Apache::ASP XMLSubs when an argument includes ''-characte rs?
Joshua Chamas wrote:
I think is just about the only thing that you can't use as
a character in the attributes for an XMLSubs and that's because
it gets parsed with an aggressive ( or stupid ;) regexp like:
$$data =~ s|\\s*($self-{xml_subs_match})([^\]*)/\
Pity!
I would like to use XMLSubs to capture some HTML-output and do
postprocess them accoring to the attributes.
Eg. if $Response-{UserName} is "Joshua" then bold part of the page.
It could be done something like this:
My:tag_it condition="$Response-{UserName} eq 'Joshua'"
start_tag='b' end_tag='/b'
..some HTML here...
/My:tag_it [Stupid example, but I hope you get the idea]
OK the tags are out. I can handle that by making an XMLSub
for every tag-pair that I need, or whatever...
But it is a pian to have to say:
% $svtwnbu=$Response-{UserName} eq 'Joshua', %
My:bold_it condition=$sbtwnbu
...more HTML here...
/My:bold_it
[Where $svtwnbu is some-variable-that-will-never-be-used elsewhere :-]
Not so neat.
Is there a simpler way of doing this?
---
Henrik Tougaard, FOA, Denmark.
RE: Question about $sth-finish;
From: Jay Jacobs [mailto:[EMAIL PROTECTED]] On Tue, 15 Aug 2000, Tom Mornini wrote: It is my understanding of the DBI docs that you only need to call $sth-finish when you DON'T fetch all the rows that the $sth has ready to return. From "Writing Apache Modules with Perl and C": "You should still call finish() at the end of each series of fetches, even though you are going to reuse the statement handler. Failure to do so can lead to memory leaks." You picked the wrong authority for this! The right place (tm) to look when discussing DBI is 'perldoc DBI'. The relevant quote is: finish $rc = $sth-finish; Indicates that no more data will be fetched from this statement handle before it is either executed again or destroyed. It is rarely needed but can sometimes be helpful in very specific situations in order to allow the server to free up resources currently being held (such as sort buffers). When all the data has been fetched from a select statement the driver should automatically call finish for you. So you should not normally need to call it explicitly. Note the last sentence! If I remember correctly, it also frees up any resources used by the database (depending on db) for the query, like for sorting, joining, etc. But I can't quote a source for that one. There is no authoritative source for that fallacy - I hope! From my point of view, it never hurts to call finish()... Quite true. Do you also undef all your variables just before they go out of scope? Thats comparable. There are a *few* situations where finish is needed (Michael Peppler has shown one, the DBI docs list another) but must DBI programmers won't need finish ever. Henrik
RE: Question about $sth-finish;
From: Vladislav Safronov [mailto:[EMAIL PROTECTED]]
What can you say about this code? is it ok (overwriting
previous handle)?
==
sub foo {
my $dbh = shift;
my $sql1 = "select *...
my $sql2 = "select *...
my $sth = $dbh-prepare($sql1);
$sth-execute;
.. fetch some data.
# should be $sth-finish inserted??
$sth = $dbh-prepare($sql2); # we overwrite previous
handle saved in $sth
..
$sth-execute;
.. fetch some data.
return;
}
==
$sth-finish should be inserted if (and ONLY if) the C...fetch some data
does NOT fetch ALL data in the select. If you do some thing like:
while (my $r=$sth-fetchrow_arrayref) {
.. handle data;
}
there is no reason to call finish, but if you do
while (...$sth-fetch..) {
last if some condition;
}
you will have to call finish, but I would reccomend using
another name for the second statement (that would help
the poor sod who will try to understand this in a years time :)
Henrik
RE: Question about $sth-finish;
From: Vladislav Safronov [mailto:[EMAIL PROTECTED]]
sub foo {
my $dbh = shift;
my $sql = ...
my $sth = $dbh-prepare($sql);
$sth-execute;
$sth-finish;
}
===
Do I always need to call $sth-finish? Wouldn't it be
automaticly called when
sub foo ends (when my variable $sth get destroyed)?
You do *NOT* need to call $sth-finish - never, never, never.
[OK. not quite true: you need to call $sth-finish when you end a
select statement before reading the last data in the cursor and
want to reexecute the select statement. So the answer is:
NEVER!!!]
If you worry about the statement handle still being defined I
would reccomend using Cundef $sth instead. That will
certainly release all resources owned by the statement.
$sth-finish is just for very special cases - and this is
not one of them.
--
Henrik Tougaard, [EMAIL PROTECTED]
RE: Bug in Apache::ASP XMLSubs when an argument includes ''-characte rs?
From: Matt Sergeant [mailto:[EMAIL PROTECTED]] On Fri, 11 Aug 2000, Henrik Tougaard wrote: With this simple .asp page I get an error: Fiks:test Start="b" /Fiks:test [My XMLSubMatch is set to Fiks:\w+ - the name of the subroutine doesn't matter] It seems as if the '' in the 'b' argument confuses the parser. [snip] Is this a (mis)feature or a parser bug? parser bug - it should have died earlier at the sign :-) XML attributes can't contain "" or "" characters, or the same quote that they are surrounded by. The following are the encodings you can use (and XMLSubsMatch needs to unravel): = "lt;" = "gt;" = "amp;" " = "quot;" ' = "apos;" Note that only "" is needed for your example (since encoding the "" isn't mandatory in XML generally). Well this does limit the usefullness of the XMLSubs feature. I had hoped that it would be possbile to use any perl expression in the attributes - as an easy way of giving arguments to the perl-sub. Pity -- Henrik
Bug in Apache::ASP XMLSubs when an argument includes ''-characters?
I have been trying to test the limits of the nice new XMLSub feature in
Apache::ASP, and seem to have discovered a bug.
With this simple .asp page I get an error:
Fiks:test Start="b" /Fiks:test
[My XMLSubMatch is set to Fiks:\w+ - the name of the subroutine doesn't
matter]
It seems as if the '' in the 'b' argument confuses the parser.
The compiled perl script is (reformatted for readability - somewhat -
everything
was on one line!):
package Fiks::Web; ;;
sub Fiks::Web::_bruger_ht00_Fagsys_www_orgvalg_fejl_aspxINL {
;; @_ = (); ;;
no strict;;
use vars qw($Application $Session $Response $Server $Request);;
Fiks::test({ Start="b }, '" '); ; ;; }
The error is:
Can't find string terminator "'" anywhere before EOF at (eval 140) line 1,
GEN10 line 1.
Is this a (mis)feature or a parser bug?
Regards
Henrik Tougaard, [EMAIL PROTECTED]
Forbundet af Offentligt Ansatte, Copehagen, Denmark.
Re: wierd problem with DBI::trace(1) and Apache (mod_perl)
On Fri, 14 Jan 2000, Cere M. Davis wrote:
I have found the weirdest problem with (I think) DBD::Ingres,
DBI::trace() and Apache::DBI when the DBI::trace level is set to 1 or 0.
I get an error in the Apache error_logs that says:
unitialized value at
/uns/mind/usr/local/perl5/lib/site_perl/5.005/alpha-dec_osf/
DBD/Ingres.pm line 85.
and than follows with text that implies that the connection was made and
In my code that line is smack bang in the middle of sub connect, the
line
unless (-d "$ENV{'II_SYSTEM'}/ingres") {
to be exact.
Why on earth that fails when line 81 is
unless ($ENV{'II_SYSTEM'}) {
I can't figure out.
Possibly your lines are not the same as mine?
I am not sure that you have connected to the database at all.
The 'normal' error here is to have forgotten to set $ENV{II_SYSTEM}
correctly - I assume that you have done that.
the data was retrived correctly. I get an error regarding my program
below:
DBD::Ingres::bind_param: parameter not a number at
/homes/clin_infr/cere/public_html/WebDBIDemo.pl line 46.
Which implies that my variable didn't get passed into the prepare
statement correctly...but I can't figure out why.
This error comes when the first argument to $sth-bind_param is not
numeric. How that can come about if the connection fails I just can't
imagine.
I suspect that this error comes about during the connection phase of the
DBI calls. Does
anyone have a suggestion for how to find out for sure?
The DBI::Ingres stuff works fine at all trace levels on the command line
but seems to have a problem with the mod_perl stuff.
If anyone has extperience to share regarding this I'd love to hear it...
Anyway, here's my system vitals:
I'm running Ingres1.2 - accessing remote database via IngresNet - DBI
version 1.13
DBD::Ingres version 0.24, mod_perl 1.21 and Apache::BDI version 0.87.
Brave man!
I havn't tested DBD::Ingres with Apache::DBI (we prefer not to allow
the web server to access the database directly) so you are trampling
on relatively virgin ground.
Some parts of Apache::DBI require cached statement handles - this is
*NOT* supported by the current version of DBD::Ingres. I have been
working on it, but my supply of tuits is low again.
---
Henrik Tougaard[EMAIL PROTECTED] (a.k.a. [EMAIL PROTECTED])
Datani A/S, Software Consultants, Copenhagen, Denmark
#include disclaim.std
