[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.
That said, I should point out that I tend to wrap my connection() method in a
subroutine anyway and call that subroutine from lots of places, so it wouldn't
be much hassle to do
Apache::DBI->connect(...)
instead of
DBI->connect(...)
. I agree that it would certainly be more intuitive and avoid the load-order
gotchas. And support for Apache::DBI could be removed from DBI, which makes
sense hierarchically.
I don't (yet) see a way to make this interface backward-compatible, so I
suppose it deserves a new class name. Apache::PersistentDBI?
Apache::CacheDBI?
------------------- -------------------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED] The Math Forum
