On Sun, Jan 18, 2004 at 12:14:22PM -0500, John Siracusa wrote:
> On 1/12/04 10:47 AM, Tim Bunce wrote:
> > And this is what I'd like you to be thinking about
> > (mostly directed at driver authors):
> >
> > A. What changes you'd like to see in the DBI API.
>
> This topic came up before, when DateTime was just getting off the ground.
> DateTime is a lot more mature now, and I still think it's a good idea :)
It is. Or at least the need is an important one and worth considering.
Thanks for the reminder.
My preference is that after doing:
$sth->bind_column(1, undef, SQL_DATE);
$sth->bind_column(2, undef, SQL_DATETIME);
$sth->bind_column(3, undef, SQL_TIMESTAMP);
the driver should ensure that it returns values for those three column in the
corresponding international standard formats (as per ODBC).
Similarly, when doing:
$sth->bind_param(1, $foo, SQL_DATE);
$sth->bind_param(2, $bar, SQL_DATETIME);
$sth->bind_param(3, $baz, SQL_TIMESTAMP);
the driver should expect to find the values given to it already in
the correct standard format for the specified type. The driver can then
convert if it needs to, but few will as the standard format is recognized
by almost all db's.
(I should also go look in the archives at what's been said before on this topic.)
Beyond that I'd like to add a way to have a callback fired when a
value is fetched. Something like:
$sth->bind_column(1, undef, { OnFetch => $code_ref });
and then you could do whatever you wanted. (I don't see a significant
need for a corresponding hook for bind_param and/or execute.)
I've been trying to avoid having the DBI take over responsibility
for setting each fetched field value, the drivers do that currently,
but I think it's enevitable. For example, few compiled drivers use
the right code to handle perl 'magic' so if you bind_column to a
tied value it doesn't work - the STORE method of the tie doesn't
get called.
> Taken to the next level (a la Perl 6 and Larry-think :) DBI 2 could
> implement all of this as part of a generic DBD-specific column type
> formatting/parsing system. But I just care about dates right now :)
I don't think a column type formatting/parsing system is needed.
But I do thing a "column type system" is needed to provide the hooks
that'll enable you to do what you want. It needs more thinking
though and, once the DBI takes over setting each fetched field values,
it can be added in without drivers having to change at all.
> I mentioned earlier that I've written a lot of DBI wrappers, and that the
> wrappers usually have some per-dbh flag that indicates whether or not I'm in
> the middle of a transaction. This is the type of thing that should be added
> to DBI 2 (see earlier thread).
Ah. I hadn't filled out the ExecuteCount description all the way:
: Count do()'s and execute()s (that aren't called by do()s) in imp_dbh.
: Make available as an ExecuteCount attribute.
: Reset count in commit/rollback.
: Add InTransaction attribute that defaults to: !AutoCommit && ExecuteCount>0
: Drivers are expected to implement InTransaction if they can.
: In $dbh->DESTROY if !AutoCommit don't rollback&warning
: unless InTransaction is true.
Thanks.
Tim.
