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>

SEE ALSO

DBIx::Password AppConfig AppConfig::Std