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 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 DBI Term::ReadKey