Charles Jardine wrote:
On 20/02/08 17:07, Martin Evans wrote:
Hi,
Just wondered if anyone else had seen this and if there are any
opinions on getting around it. I use DBIx::Log4perl (which I wrote to
help debug our DBI appication) and DBD::Oracle. New code added to our
application calls an oracle package function which returns a reference
cursor and it is bound in Perl like so:
my $sth2;
my $sth1 = $h->prepare(q{BEGIN ? := pkg.testfunc; END;});
$sth1->bind_param_inout(1, \$sth2, 0, { ora_type => ORA_RSET } );
as per DBD::Oracle pod. After $sth1->execute, $sth2 is a statement
handle but DBIx::Log4perl does not know about it and hence when it is
used it leads to errors in DBIx::Log4perl when it accesses private
attributes it usually stores in the statement handle (e.g. a Log4perl
log handle) which are not present. i.e., normally when the application
calls the prepare method, DBIx::Log4perl sees the returned statement
handle and does something like:
my $sth = $dbh->SUPER::prepare(@args);
$sth->{private_DBIx_Log4perl} = $log_handle if ($sth);
but DBIx::Log4perl did not see this magically returned statement handle.
These statement handles are presumably of the correct class.
All that is wrong with them is that DBIx::Log4perl has not
has a chance to initialise them. They have never been through
prepare or execute, but are nevertheless ready to fetch from.
One approach would be to modify all the fetch methods in
DBIx::Log4perl to expect uninitialised statement handles and
initialise on demand.
You will also have to cope with the fact that these handles
do not have useful Statement attributes.
Thanks Charles.
I had thought about initialising on demand but thought there would be
quite a lot of methods to do that in. As it turns out there are as you
say basically the fetch and finish methods.
I'm not sure useful of not statement attributes will affect me but we'll
see when I fix the first problem.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
