On 1/19/04 7:41 PM, Tim Bunce wrote:
> On Mon, Jan 19, 2004 at 07:19:05PM -0500, John Siracusa wrote:
>> What about the other direction, allowing arbitrary code
>> (\&my_deflate_thingie) to run during calls like:
>>
>> $sth->execute($val1, $val2, ...);
>
> I'm much less inclined to do that. Smart thingies can stringify.
Yeah, but stringify to what? Probably not the db-specific thingies they
need to become since they have little or no way of knowing what context
they're in (i.e. which DBD) when they're asked to stringify.
> Execute is called less often than fetch and with more direct control,
> unlike, for example, selectall_arrayref().
I think we have two different goals here :) I'm trying to foster more
database independence by allowing the same end-user code to transparently
"inflate" and "deflate" (to use your terms) column values. The idea is
that, when Joe Progammer changes from MySQL to Postgres, he doesn't have too
pore over all his code replacing all his \&my_inflate_thingie hooks, calls
to deflate_mysql_datetime(), and so on.
In the case of the bind_columns() hooks, it looks like the changes would
probably only have to be done in a few places (which is a few more than I'd
like, but anyway... ;)
In the case of calls to execute() and string-assembled SQL, the conversion
task is much more daunting. Imagine if a user changing from MySQL to
Postgres also had to go through all his code and change all the calls of
mysql_quote_int() and mysql_quote_datetime() and so on to
Pg::TypeQuote->quote('int', $val), PG::TypeQuote->quote('timestamp', $val),
etc.
Thankfully there's $dbh->quote() which Does the Right Thing for each
database when called from a $dbh of a given type.
What I'm looking for is a similar family of functions for coercing (probably
a better term than "inflating" or "deflating") column values on both input
and output in a transparently database-independent way. That is, without
the DBI user having to know or do much more than he has to know or do when
quoting values with $dbh->quote()
Maybe you think that type of thing doesn't belong in DBI because it is too
high-level or substantially more complex than quoting, but it's a common
enough task that there should be *some* standardized framework for doing it.
While DateTime::Format::DBI is a nice step in the right direction, it's not
even half proper a solution without a transparent, bi-directional interface
with DBI. Ideally, this DBI column coercion interface would define its own
API rather than molding itself to the vagaries of DateTime::Format::DBI.
That way, DBI users could choose whatever column value coercion module(s)
they wanted--or use none at all and incur no additional overhead vs. plain
old DBI today.
Maybe a wrapper (or subclass?) really is the right solution. But IMO this
stuff is not so far outside of DBIs traditional domain. Things like
selectall_arrayref() are already pretty high-level, and $dbh->quote() is the
model of what could be achieved, albeit on a larger scale this time.
-John
