view release on metacpan or  search on metacpan

ANNOUNCE-FACTOR.pod  view on Meta::CPAN

=head1 The refactoring

The module DBIx::DBH represents my refactoring of Dave's code. The
hash elements have slightly different naming:

=over

=item * the database driver must be supplied

The C<driver> key is used to supply the database

=item * the name key is dbname

=item * the pass key is passed

=back

Another difference is that _make_dbh() called C<< DBI->connect() >> with a
fixed set of DBI attributes. The refactoring allows for any attributes
to be used, both from DBI and from the driver's driver.

=head1 Database Connection Modules, Past and Present

The very first module on CPAN for database connection may have been
C<DBIx::Password> by Brian Aker.  I sent him patches so he could
return a hash of data or array of data for use with supra-DBI tools
like L<Alzabo> and L<DBix::AnyDBD> but he refused them. L<Ima::DBI>
was also available around this time, but it simply slipped my mind.

So in 2002, I created DBIx::Connect, a Perl module which would 
use L<AppConfig> configuration files to provide either DBI database handles
or a data structure with connection information. This was nice because I could
flit from database tool to database tool but only have to catalog my
connection information once.

However, DBIx::Connect was based on AppConfig, which was proving itself
hard to use - it was not easy to have global data and overwrite it
in sub-blocks. I noted these shortcomings here:

   http://perlmonks.org/?node_id=299749

and based on suggestions rewrote DBIx::Connect from the bottom up using
Sam Tregar's excellent L<Config::ApacheFormat>. Now, I could do
anything with config files that you could do with an Apache one. Also, 
I had much better validation of the config file.

L<Config::DBI> is OK except for two things

=over

=item 1  DSN strings are entered as one composite value. 

When using an Apache-like configuration file, one thing you find
immensely useful is the ability to build up your data in layers,
inheriting and over-writing values as necessary.

It is difficult to create such an inheritance hiearchy
describing each database when the DSN is specified as a string.

=item 2 Config::DBI has rigid expectations of the config file

Software organizations should be entitled to develop configuration
files in any manner they desire. Config::DBI expects the file to have
a certain structure which may not accord with how the organization
wants to describe their database setup

=back

The way around both of these problems was handled by Alzabo's
make_dbh() function a long time ago. To handle item 1, you simply run
through the hash, looking for keys that can be used in the DSN and
assemble them into the DSN string. To handle item 2, you simply expect
a hash whose keys are limited to the values in the DBI and driver
documentation. How a particular software organization transforms their
internal configuration information to this generic hash is their concern.