> Er, yeah, "essentially" :) All the crazy re-blessing that goes on is quite > a mess, IMO.
Agreed. I would like to replace Apache::DBI with something oriented towards connection management rather than porting old CGI scripts. I don't like the disabling of disconnect. The old Apache::DBI could stick around just for that purpose. > So what you're saying is that DBIx::* and Apache::DBI will simply > never get > along because they both want to do the same thing, but use different > (and > apparently incompatible) methods to do so? They both subclass, and multiple inheritance might not work here, but you can try it. Put this code somewhere after you load Apache::DBI: psuh @Apache::DBI::st::ISA, 'DBIx::ContextualFetch'; Note that this has nothing to do with DBIx::* as a whole. This one particular module that you are using happens to subclass DBI. Most of them don't. > The first answer is that I'm calling disconnect because it's The Right > Thing To Do. I can't see how. You know it's a no-op. You don't actually want it to disconnect. Why call it? The whole disabling-disconnect thing exists only for the purpose of porting old CGI scripts. > Maybe some people think just letting things go out of scope is more > "(mod_)perl-ish", but I always wonder if those people don't call > close(FILE) either ;) Now that Perl has lexically scoped filehandles, there isn't any reason to explicitly call close() in most cases. ;) > The second answer is that it's common (and usually desirable) for > certain DBI-using modules to be used both in both web and offline > contexts. I share a lot of code that way too, but I typically keep the connection open until the end of the command-line script and then close it there. - 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
