On Wed, Feb 13, 2002 at 11:36:36AM -0800, Jonathan Leffler wrote:
> Hi - another question:
>
> The sample code for DBD::Driver::db::prepare starts:
>
> sub prepare
> {
> my ($dbh, $statement, @attribs) = @_;
>
> # create a 'blank' sth
> my $sth = DBI::_new_sth($dbh, {
> 'Statement' => $statement,
> });
>
> Question: does DBI keep track of the statement text, or do the DBD
> modules all have to do it?
The DBD does it via the code above.
> If DBI tracks it automatically, does that make the above code wrong,
> or just superfluous?
It's needed.
> If DBI does not track it, that presumably means that the DBD FETCH
> functions have to handle it, whereas if DBI does track it, then they
> don't.
The code above basically pre-caches the Statement in the attribute cache
of the handle.
> Is the statement text a read-only attribute of the statement
> handle?
Yes. You can tell this because there's no entry for it in dbih_set_attr_k()
in DBI.xs.
> If not, why not, and what are the semantics of:
>
> $sth->{Statement} = "some new SQL";
Fatal error.
> Consider the cases where the original statement is a SELECT and the
> statement handle has been executed and maybe some data has been fetched,
> as well as before the statement is executed and after the statement is
> finished.
>
> If DBI tracks it and the DBD also tracks it, then which one 'wins'?
The only 'tracking' that the DBI does is
if (ima->flags & IMA_COPY_STMT) { /* execute() */
SV *parent = DBIc_PARENT_H(imp_xxh);
SV **tmp_svp = hv_fetch((HV*)SvRV(h), "Statement", 9, 1);
hv_store((HV*)SvRV(parent), "Statement", 9, SvREFCNT_inc(*tmp_svp), 0);
}
which copies the Statement attribute from the statement handle up to the database
handle when execute() is called.
> The
> user loses, of course, because more work is being done than necessary.
> But does DBI use its own version of the statement text or does it end up
> using the driver's version?
It uses whatever $h->{Statement} returns.
> I ask because DBD::Informix currently tracks Statement for itself, more
> or less as implied by the code above. This has consequences for the
> FETCH code (which does recognize it) and the STORE code (which declines
> to do anything with it.
I'm not sure what the issue is here, or what you mean by 'tracking'.
But maybe that's just my head cold...
Tim.
