"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