Re: using DBI handles managed elsewhere

[prev] [thread] [next] [Date index for 2005/04/05]

On Apr 4, 2005 7:03 PM, Tony Bowden <tony-cdbitalk@xxxxx.xxx> wrote:
> On Mon, Apr 04, 2005 at 11:47:21PM +0100, Tim Bunce wrote:
> > I think Class::DBI can (and should) be altered to not depend on
> > DBIx::ContextualFetch. It would mean duplicating some DBIx::ContextualFetch
> > functionality within Class::DBI. It's not much code and, to my mind, the
> > benefits outweigh the philosophical concerns.
> 
> I disagree, but I'll certainly listen to the argument.
> 

I came across issues with this when introducing CDBI to a legacy
application over 6 months back. I had to introduce a set_dbh method
and rework db_Main in the base CDBI class so that I can pass in an
instantiated DBI object.  I had to tweak the legacy application to use
ContextualFetch as RootClass.  Ultimately, I got it to work with
version 0.95, but I couldn't eventually get it to work with 0.96. 
Sorry I don't have more details here. I think many of the posts by
Perrin Harkins related to mod_perl and CDBI may actually be what I was
looking for at the time.

I've used CDBI in several contract projects using the ideal
__PACKAGE__->connection(...) in the base class. I know the full
benefits I can get from using CDBI, but I could see how someone else
may give up entirely, especially since I had come pretty close to
doing so myself.

Many legacy systems I've come across have a well entrenched way of
connecting to a database which many other parts of the system depend
on.  Ideally, I would like to simply use whatever DBI object is
available under these circumstances.