AppConfig::DBI - AppConfig-based support for DBI connection and connection data

[ this is pre-CPAN until Monday ]



NAME
     AppConfig::DBI - AppConfig-based support for DBI connection and
     connection data

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=1"

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 [email protected] both made strong arguments in
     favor of AppConfig.

   EXPORT

     None by default.

AUTHOR
     T. M. Brannon <[email protected]>

SEE ALSO
     DBIx::Password AppConfig AppConfig::Std