I have a module which makes connections to databases via the Perl
DBI by way of
information stored via AppConfig (ABW's CPAN module)... which
actually means
via an AppConfig file or via simple or complex command-line
control. Docs included below.
I am torn between naming it AppConfig::DBI and DBIx::Connect.
Randy Ray made a great
point when he thought that naming it AppConfig::DBI would imply
that I had implemented
a way of configuring apps via databases. So I renamed it DBIx::Connect.
Perhaps DBIx::AppConfig::Connect is the best name?
NAME
DBIx::Connect - support for DBI connection (info) via AppConfig
SYNOPSIS
# .cshrc
setenv APPCONFIG /Users/metaperl/.appconfig
setenv DBIX_CONN "${APPCONFIG}-dbi"
# .appconfig-dbi
[basic]
user = postgres
pass = <STDIN>
dsn = dbi:Pg:dbname=mydb
attr RaiseError = 0
attr PrintError = 0
attr Taint = 1
# DBIx::AnyDBD usage:
my @connect_data = DBIx::Connect->data_for('dev_db');
my $dbh = DBIx::AnyDBD->connect(@connect_data, "MyClass");
# pure DBI usage
use DBIx::Connect;
my $config = shift or die "must give label for config";
my $dbh = DBIx::Connect->to($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=0"
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, "to" and "data_for" which return a
DBI database
handle and 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 also 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. DBIx::Connect 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, used to use
on-the-fly Config
modules and Net::FTP::Common did 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, DBIx::Connect can add configuration
information upon
invocation via the command-line or via the
"read-from-STDIN-flag",
"<STDIN">, 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
vis-a-vis connection, DBIx::Password has one method,
"connect" which
returns a $dbh. While DBIx::Connect also supplies such a method
(named "to"), it also supplies a "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 DBI Term::ReadKey
$terrence = {
hobby => Class::MakeMethods -> hacker (type => 'Just Another'),
addiction => 'Chess on ICC as princepawn',
job => 'seeking' ,
URL => 'http://www.metaperl.com'
};
