On 1/18/04 6:33 PM, Tim Bunce wrote:
> 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.
>
> 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.)
These are all good suggestions, but to implement them you'll need an API
similar to the one I described. Sure, it could be internal or non-standard,
but that'd miss the point of my proposal. Not all parsing/formatting can be
conveniently done at "bind columns" time. Indeed, not every DBI use case
even calls for binding columns. Whether or not what you described is
implemented, I think we still need a user-visible API like the one I
described that can be use outside of bind_columns() on any data at any time,
so long as there's a $dbh available.
>> 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.
Having DBI twiddle fetched values for me is useful, but I'd also like the
lower-overhead option of doing it myself only when I need to via explicit
calls to parse_*() and format_*()functions. I'd also much rather deal with
DateTime objects as the interchange format, not ISO date strings, especially
when date math and comparisons are called for.
DateTime objects are heavyweight too, so maybe ISO dates could be used as
the interchange format in the bind-columns-driven DBD-independent system
that you describe, but then I'd like a DBD-specific parsing/formatting API
to be built on top of that :) That's something each DBD author would have
to add, but a common "internal" interchange format (ISO dates) might make
that easier. The DBDs would also have to implement the keyword parsing,
pass-through, and translation.
-John
