"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:

> Ken Williams wrote:
> > 
> > [EMAIL PROTECTED] (Jeffrey W. Baker) wrote:
> > >IMHO Apache::DBI causes more problems than it solves with it's
> > >"transparent" replacement of DBI functions.  Can anyone point to an
> > >example where a subclass of DBI would not do everything that Apache::DBI
> > >does, except without the headaches?
> > 
> > Yes, here's an example: a subclass wouldn't let existing scripts run
> > *unmodified* with persistent connections.
> 
> Well, yeah.  I think that's the point.  In any rational world, you
> wouldn't expect the loading of a class called Apache::DBI to affect the
> methods of the class called DBI.
> 
> Apache::DBI is a weird class.  Most people never call any methods from
> it.  For them, the incantation 'use Apache::DBI;' is pure voodoo
> programming.

It's a good example of the "action at a distance" idea.  It's useful,
though, so we can forgive some amount of trouble :)  It would be nice
to see a DBD::Apache or DBD::Shared DBD module, so that you could call
something like:

my $db = DBI->connect("shared;dbd=mysql;db=mydb;host=foo.com", "myuser",
                      "mypw");

Then the DBD module could handle the caching of handles at that
level.  Or as suggested above you could subclass DBI.

I think we should provide both a clean, well-designed interface for
general use, and an interface that works with existing scripts
un-modified.  Come to think of it, most cases that would want to run
unmodified probably are Apache::Registry scripts.  Perhaps the db
handle caching belongs somewhere with Registry, much as it handles
caching of parsed scripts?  There would be a certain aesthetic value
of Registry caching dbh's as well as scripts and letting a separate,
on-demand module handle general caching for typical handlers to use.

Even nicer would be Registry using that same higher level mechanism
with only slight amounts of magic :)

Like $[, Apache::DBI serves a purpose for backwards compatibility (in
this case old CGI scripts instead of odd perl4 scripts), but it
probably should be disdained in general use, at least once a suitable
replacement is available.  Now, who wants to write it? :)

Chip

-- 
Chip Turner                   [EMAIL PROTECTED]
                              Programmer, ZFx, Inc.  www.zfx.com
                              PGP key available at wwwkeys.us.pgp.net

Reply via email to