On Sun, Mar 07, 2010 at 10:29:29AM -0800, David E. Wheeler wrote:
> On Mar 7, 2010, at 5:43 AM, Tim Bunce wrote:
>
> >> Looks good, thanks. Pity you removed the `$dbh->{private_myapp_sql_mode}`
> >> bit, though, as that's required when using C<connect_cached()>, which
> >> you almost certainly are doing if you need this hack.
> >
> > Are you sure it's required when using connected()? The connected method
> > is only called for new connections.
>
> Yes, I just verified it with Bricolage, which uses connect_cached.
> connected() is called every time, whether or not a connection is a new
> connection.
Uh, yeah, I just looked at the code. Sometimes I confuse myself.
I think that's a bug. I always intended connected() to be used as an
on-new-physical-connection-established hook.
Any objections to making it so?
Looking at the code I can see an issue with clone(): it'll clone using
the same method (connect/connect_cached) as the handle that's being
cloned. I guess I can document that as a feature :)
> BTW, here's another issue I forgot to mention. I installed the DBI
> from svn and now get this error unless I rebuild each driver:
>
> [Sun Mar 07 10:22:24 2010] [error] DBI/DBD internal version mismatch
> (DBI is v95/s208, DBD ./mysql.xsi expected v94/s208) you probably need
> to rebuild the DBD driver (or possibly the DBI).
>
> I've never had an issue with binary compatibility between the DBI and
> a DBD. Did something change in this last build?
Yes, the additional hook for sql_type_cast_svpv. But I shouldn't have
bumped DBISTATE_VERSION for just that - the change was binary compatible
with old drivers. (Drivers that care can use the DBIXS_REVISION macro
to check if sql_type_cast_svpv is available at compile time and check
it's non-zero to check it's available at runtime.)
Fixed in r13837. Thanks.
Tim.
