On Fri, 2004-08-13 at 16:43, John Siracusa wrote: > It > just seemed odd to me to be doing stuff in service of Apache::DBI, which was > totally transparent until then.
That's one of the things I don't like about Apache::DBI. I don't want it to be magical. > > Now that Perl has lexically scoped filehandles, there isn't any reason > > to explicitly call close() in most cases. ;) > > Tsk, for shame. Just wait until you forget to call close() after writing to > a file... ;) That's the point actually -- perl closes it for me when it goes out of scope. > That assumes the connection was opened by (or is at least accessible from) > the script itself. If the connection is opened and managed by a module > (which may abstract things such that you aren't even supposed to know > whether or not it has to hit a database at all) rather than by your script, > that's not an option. True, you have to structure your code for this. Making all calls to open a db connection go through one utility class is my approach, but may not work for everyone. Hmm, I wonder why my Class::DBI unit test scripts never get the disconnect warning? I should look into that. Class::DBI uses connect_cached. > I also wrap DBI rather than subclass it when I have a choice. Me too. Subclassing DBI (or Apache or Apache::Request for that matter) is nearly always a bad idea IMO. In this one case it makes some sense though, since that module is literally all about changing the behavior of DBI methods. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
