On Mon, Jan 07, 2002 at 07:11:32AM -0500, Terrence Brannon wrote:
>
> On Thursday, January 3, 2002, at 08:11 AM, Tim Bunce wrote:
> >
> > People could, if they want, think of the changes I'm proposing as
> > being suited to providing simpler implementations of modules like
> > DBIx::Abstract, DBIx::AbstractLite, DBIx::Broker, DBIx::Cache,
> > DBIx::DWIW etc.
> >
> >
>
> yeah, all of those modules were written as packages with methods.
> the other way that a Perl module which requires DBI database
> handles to do its work is exemplified by PApp::SQL, also on CPAN.
>
> What he does instead is something like this:
>
> $sth = sql_exec [dbh,] [bind-vals...,] "sql-statement",
>
> and then if no dbh is given, then he looks in the current package
> for a variable called $DBH and then he looks in
> $PApp::SQL::DBH for such a variable. The first one he finds he
> uses as the database handle for the call.
>
> And I might also mention that I recently took all of the DBI
> convenience functions in the AnyDBD distribution and rewrote them
> to use a similar $dbh search protocol.
Seems like you're creating a whole bunch of duplicate code with
little reuse.
It would seem better to create a module that implements the concept
in a more generic way. Perhaps something like:
use AutoObject class => DBI::db, obj => sub { $main::DBH || $PApp::SQL::DBH };
that would import into the current package stubs for all the DBI::db
methods so they could be used as functions. The stubs would use the
specified dbh=>... hook code to get the $dbh to use then call the
corresponding method.
> It is available on CPAN as
> DBIx.... that's right, plain DBIx.
Not a good name really (unlikely to get into the Module List).
Tim.
