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 'Tain
+t=1'
[download]

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