Re: CDBI and mod_perl

[prev] [thread] [next] [Date index for 2005/02/20]

On Sun, Feb 20, 2005 at 04:31:58PM -0500, Perrin Harkins wrote:
> I was thinking you would proxy the other stuff with AUTOLOAD.  It 
> doesn't matter what other people do with the $dbh, as long as everything 
> Class::DBI wants to do with it works on this proxy version of 
> ContextualFetch.  Other people can just use the $dbh directly.

That's non-trivial, considering the magical nature of a $dbh. 

> What you get is the ability to use Class::DBI with database handles that 
> were not originally created for Class::DBI use.  For example, I am 
> trying to do some work with Class::DBI in extensions to the Krang CMS. 
> Krang has its own mechanism for getting a database handle, which 
> includes application-specific logic about picking the right connection 
> to use.  I'd like to be able to override db_Main() and have it call the 
> Krang database access routine and just use the $dbh it gets back, but I 
> can't because that handle is not subclassed into the 
> DBIx::ContextualFetch class.  If I re-bless it, I may break things in 
> the rest of the Krang application when it gets unexpected results from 
> using the $dbh.

It's not really a matter of reblessing it (DBI is much too magical for
that) - it's a matter of setting the RootClass attribute on it.

I don't really see what that could break, unless Krang already uses a
different RootClass, in which case the whole thing is going to be
incompatible anyway.

> This problem would be the same with integrating Class::DBI into any 
> existing system that manages the opening of database handles, 

In general it should just be a matter for the handle-management system
to factor the code out for deciding what DBI the connection information
should be from the code that then connects. Then the normal code can
call the part that gets the connection, but the CDBI part can call one
level deeper than that and feed the connection information to its own
->connection() method. That should account for at least 99% of the
common cases.

> or any situation where Class::DBI needs to share handles with
> non-Class::DBI code that expects standard behavior from DBI.

DBIx::ContextualFetch doesn't really change DBI behaviour, it extends
it. Adding it to any $dbh that doesn't have another RootClass should be
safe in 99.99% of cases.

Tony