AppConfig::DBI - support for DBI connection (info) via AppConfig
# .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"
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.
The only module similar to this on CPAN is DBIx::Password. Here are some points of comparison/contrast.
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.
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.
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.
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.
None by default.
T. M. Brannon <tbone@cpan.org>