NAME

AppConfig::DBI - support for DBI connection (info) via AppConfig

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=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, 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 p5ee@perl.org both made strong arguments in favor of AppConfig.

EXPORT

None by default.

AUTHOR

T. M. Brannon <tbone@cpan.org>