[ this is pre-CPAN until Monday ]
AppConfig-DBI-0.01.tar.gz
Description: GNU Zip compressed data
NAME
AppConfig::DBI - AppConfig-based support for DBI connection and
connection data
SYNOPSIS
# .cshrc
setenv APPCONFIG /Users/metaperl/.appconfig # dont forget
the dot!!!
setenv APPCONFIG_DBI "${APPCONFIG}-dbi"
# .appconfig-dbi
[basic]
user = postgres
dsn = dbi:Pg:dbname=mydb
attr RaiseError = 0
attr PrintError = 0
attr Taint = 1
# DBIx::AnyDBD usage:
my @connect_data = AppConfig::DBI->connect_data_for('dev_db');
my $dbh = DBIx::AnyDBD->connect(@connect_data, "MyClass");
# pure DBI usage
use AppConfig::DBI;
my $config = shift or die "must give label for config";
my $dbh = AppConfig::DBI->connect($config);
# over-ride .appconfig-dbi from the command line:
perl dbi-script.pl basic -basic_user tim_bunce -basic_pass
dbi_rocks
perl dbi-script.pl basic -basic_attr "RaiseError=1"
-basic_attr "Taint=1"
DESCRIPTION
This module facilitates DBI-style or DBIx::AnyDBD-style database
connections for sites and applications which make use of
AppConfig to
configure their applications via files and/or command-line
arguments.
It provides two methods, "connect" and "connect_data_for"
which return a
DBI database handle or an array of DBI connection info,
respectively.
Each of the 4 DBI connection parameters (username, password,
dsn, attr)
can be defined via any of the methods supported by AppConfig,
meaning
via a configuration file, or simple-style command-line arguments.
AppConfig provides support for both simple and Getopt::Long
style, but
Getopt::Long is overkill for a module this simple.
RELATED MODULES / MOTIVATION FOR THIS ONE
The only module similar to this on CPAN is DBIx::Password.
Here are some
points of comparison/contrast.
* DBI configuration info location
DBIx::Password uses an autogenerated Perl module for its
connection
data storage. AppConfig::DBI uses a Windows INI-style
AppConfig file
for its connection information.
The advantage of a config file is that each programmer
can have his
own config file whereas it could prove tedious for each
programmer
to have his own personal copy of a Perl configuration module.
Not to mention the fact that if each Perl module in your large
application went this route, you would be stuck with n-fold Perl
configuration modules as opposed to one centralized
AppConfig file.
For example, my module SQL::Catalog, also uses on-the-fly Config
modules and Net::FTP::Common does as well.
* Routes to configurability and password security
DBIx::Password DBI connection options (username, password, dsn,
attr) are not over-ridable or settable at the command line. This
means passwords must be stored in the configuration file
and that
efforts must be taken to make a module readable by a program not
readable by a human.
In contrast, AppConfig::DBI can add configuration
information upon
invocation via the command-line which will overwrite or set
arguments which could have been in the configuration file, which
means your passwords need not be stored on disk at all.
* Support for indirect connection
DBIx::Password has one method, "connect" which returns a
$dbh. While
AppConfig::DBI also supplies such a method, it also supplies a
"connect_data_for" method which returns an array which
can be passed
to any other DBI connection scheme, the must ubiquitous
of which is
DBIx::AnyDBD, which handles connections for you after you
give it
the connection data.
I submitted a patch to the author of DBIx::Password to
support such
functionality, but it was rejected on the grounds that
DBIx::Password is designed to secure connection data, not
make it
available in any form or fashion.
My CPAN module set will be AppConfig-dependant
From now on, any module of mine which requires configuration
info will
use AppConfig to get it. I thought about using XML but a
discussion on
Perlmonks.Org and one on [EMAIL PROTECTED] both made strong arguments in
favor of AppConfig.
EXPORT
None by default.
AUTHOR
T. M. Brannon <[EMAIL PROTECTED]>
SEE ALSO
DBIx::Password AppConfig AppConfig::Std
