RE: [dbi] Re: execute not seen on selectrow_* for suclassed DBI

Tim,

Thanks, I do keep forgetting about Driver.xst.

So, just to be clear. In DBI.pm, selectrow_array calls _do_selectrow which
calls prepare/execute/fetchsomething but this may be overriden by a driver
using selectrow_array in Driver.xst. If this is the case:

a) is there any way for my subclassed DBI to know this?
b) is there an easy way to identify which other methods this could apply to

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com


On 29-Mar-2006 Tim Bunce wrote:
On Wed, Mar 29, 2006 at 11:54:32AM +0100, Martin J. Evans wrote:
The issue I am seeing is not quite as general as I made it sound. For
selectrow_hashref I see prepare/execute/fetch/fetchrow_hashref (as I expect)
but
for selectrow_arrayref and selectrow_array I only see prepare.

Generally... Drivers are free to implement any method in any way they choose.
Their own methods don't have to call execute(), for example.

Specifically... you're probably seeing the effect of the Driver.xst
C code that most compiled drivers embed into themselves. That code
embeds C implementations of selectall_arrayref and several other
methods into the driver itself. The selectall_arrayref code calls the
drivers C functions to do the work. The result is much, much, faster
than going though perl/DBI method dispatch for each row.

Tim.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com


On 29-Mar-2006 Martin J. Evans wrote:
Hi,

I have subclassed DBI and override many methods including prepare, execute
and
select* although they are predominantly just passed on to DBI.

If I do:

my $sth->prepare(sql);
$sth->execute;

I see the prepare and execute and pass them on to DBI.

If I do:

$dbh->selectrow_array(sql);

I see prepare and pass it on, but do not see execute. In my case this is
more
than an annoyance as I cannot see any bound parameter passed to execute.

e.g.

$selectrow_array = [
'select b from mytest where a = ?',
undef,
\1
];
prepare: select b from mytest where a = ?
!!! no execute here

Or, perhaps I'm doing something wrong.

Can anyone tell me if I should be seeing the execute when $dbh->select***
is
called? I think I should.

Thanks

Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
.

Relevant Pages

  • Re: documentation bugs on LongRealLen
    ... -A value of 0 means not to automatically fetch any long data. ... The default is typically 0 bytes but may vary between drivers. ... execute an extra select statement to determine the longest value. ... -See Lfor more information on truncation behaviour. ...
    (perl.dbi.users)
  • Re: execute not seen on selectrow_* for suclassed DBI
    ... Drivers are free to implement any method in any way they choose. ... Their own methods don't have to call execute(), ... On 29-Mar-2006 Martin J. Evans wrote: ... I have subclassed DBI and override many methods including prepare, ...
    (perl.dbi.users)
  • Re: [dbi] Re: execute not seen on selectrow_* for suclassed DBI
    ... Not seeing execute on a selectrow_array threw me initially ... Martin J. Evans ... C code that most compiled drivers embed into themselves. ...
    (perl.dbi.users)
  • Re: [dbi] Re: execute not seen on selectrow_* for suclassed DBI
    ... Martin J. Evans ... Drivers are free to implement any method in any way they choose. ... Their own methods don't have to call execute(), ...
    (perl.dbi.users)
  • Re: most drivers share error variable for sth/dbh handles?
    ... Each database handle has a copy of the most recently executed statement's ... $dbh->err here would be what $sth->err was above in the eval after the execute. ... "The DBI resets $h->err to undef before almost all DBI method calls, ... Given the "most drivers" above I presume some drivers don't share the ...
    (perl.dbi.users)