Re: Class::DBI over DBD::AnyData - solved?

[prev] [thread] [next] [Date index for 2004/11/27]

On Fri, Nov 26, 2004 at 06:28:06PM -0500, Dan Friedman wrote:
> Well, I played with it some more, and I have something that works, but it's
> very much a hack. In order to get around the Ima::DBI caching problem, I can do
> this:
> 
> - define a temporary _carp subroutine that filters out /select_.*\salready\sexists/ 
> - no warnings "redefine"
> - redefine Class::DBI::_carp() to use my _temp_carp
> - override set_sql so it calls $class->SUPER::set_sql($name, $sql, $db, 0)
> - redo all the set_sql calls in Class::DBI (under 'SQL we'll need', line 125)
> - put back the original Class::DBI::_carp() sub
> - use warnings "redefine"
> 
> Now I have what I wanted: the DBD doesn't support prepare_cached,

Drivers don't: prepare_cached is a service provided by the DBI.

> so I'm not
> using it anymore, and I'm not getting the warnings about active statement
> handles anymore. I can now use Class::DBI to access AnyData databases;
> everything appears to just work.
> 
> However, I'm concerned that the techniques I've used to accomplish this are Bad
> Ideas.

Yeap.

> OTOH, is this something others would find useful? I'm still happy to
> hear of less hackish solutions to deal with this, but in the meantime, I'm
> tempted to try all (or many of) the Class::DBI tests out on it and see if I can
> publish it as Class::DBI::AnyData. Thoughts? Suggestions? Encouragement?
> Discouragement?

Finding and fixing the actual cause seems better than assorted hacks
to avoid the warning.

Seems like the Active attribute isn't getting reset. Probably means
the finish() methods isn't working right. Take a look. Use DBI trace().

Tim.

p.s. You only said "*seems* to produce warnings about active statement handles"
and didn't give the version numbers of the relevant modules (Class::DBI and
DBD::AnyData, at least).