On Wed, 2003-08-13 at 17:30, Matt Sergeant wrote:
Unfortunately Apache::DBI is an ugly "action at a distance" hack :-)
I agree, but having everyone implement their own is worse. It leads to lots of repeated work on solved problems. What would you suggest to fix it?
My idea would be to leave Apache::DBI as it is for use with legacy CGI code and then add a new module to the distribution that is called explicitly so it has no "distance" issues. Maybe call it Apache::DBI::Factory?
There could also be an attempt to reconcile Apache::DBI with DBI->connect_cached. AFAIK, the only features Apache::DBI has over connect_cached are the rollback cleanup handler and the transparency part, which we don't like. Apache::DBI::Factory could just call connect_cached and add the cleanup part.
Don't forget that I've started working on DBI::Pool, which should work transparently for threads and processes with and without mod_perl. So if you want to spend any effort on a replacement for Apache::DBI, I'd suggest to join the efforts. At the moment I'm too busy with mp2 issues, so if anybody wants to pick the flag and get the module past the prototype phase, that would be great.
It has no external face yet, so you can do whatever you want. the hard part was to provide an internal support from DBI, which is almost there.
Check this thread: http://archive.develooper.com/[EMAIL PROTECTED]/msg02134.html
There was a lot of discussion happening around this item: http://www.geocrawler.com/mail/thread.php3?subject=rfc%3A+DBI%3A%3APool+prototype+%28i.e.+hack%29&list=184
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
