DBIx::DBH::Legacy - legacy helper for DBI connection data (form dsn, etc)


 use DBIx::DBH::Legacy;

 my %opt = (tty => 1) ;
 my %dat = ( 
     driver => 'Pg',
     dbname => 'db_terry',
     user => 'terry',
     password => 'markso'

 my $dbh = DBIx::DBH::Legacy->connect(%dat, %opt) ; # yes, two hashes, not hrefs!


DBIx::DBH::Legacy is designed to facilitate and validate the process of creating DBI database connections. It's chief and unique contribution to this set of modules on CPAN is that it forms the DSN string for you, regardless of database driver. Another thing about this module is that it takes a flat Perl hash as input, making it ideal for converting HTTP form data and or config file information into DBI database handles. It also can form DSN strings for both major free databases and is subclassed to support extension for other databases.

DBIx::DBH::Legacy provides rigorous validation on the input parameters via Params::Validate. It does not allow parameters which are not defined by the DBI or the database driver driver into the hash.

It provides support for MySQL, Postgres and Sybase (thanks to Rachel Richard for the Sybase support).


This module does not appear to be very useful at first. But it has it's place. Let's see why.

Simple, robust DSN formation


Let's take a look at a DBI connection string:

       $username, $password);

Now, notice: how the dsn contains a lot of subelements:

1. dbi
2. mysql
3. database
4. host
5. port


This module is robust. It uses Params::Validate to make sure that what you supply is valid.

Easier interaction with APIs

Rose::DB::register_db() expects sub-components of a DSN

If you take a look at a call to register_db:

you will notice that it requires the sub-components of the DSN. So, ideally you would be able to keep your connection data as a set of sub-components and supply it to Rose::DB but when you want to connect directly to DBI, you could do that also.

This module is the solution for this dilemma as well.

Alzabo and DBIx::AnyDBD have alternative connection syntaxes

Alternative connection syntaxes such as DBIx::AnyDBD or Alzabo can make use of the connect_data API call


$dbh = connect(%params)

%params requires the following as keys:

  • driver : the value matches /\a(mysql|Pg)\Z/ (case-sensitive).

  • dbname : the value is the name of the database to connect to

%params can have the following optional parameters

  • user

  • password

  • host

  • port

%params can also have parameters specific to a particular database driver. See DBIx::DBH::Legacy::Sybase, DBIx::DBH::Legacy::mysql and DBIx::DBH::Legacy::Pg for additional parameters acceptable based on database driver.

($dsn, $user, $pass, $attr) = connect_data(%params)

connect_data takes the same arguments as connect() but returns a list of the 4 arguments required by the DBI connect() function. This is useful for working with modules that have an alternative connection syntax such as DBIx::AnyDBD or Alzabo.

$dsn = form_dsn(%params)

form_dsn takes the same arguments as connect() but returns only the properly formatted DSN string. This is also useful for working with modules that have an alternative connection syntax such as DBIx::AnyDBD or Alzabo.


Simply add a new driver with a name of DBIx::DBH::Legacy::$Driver, where $Driver is a valid DBI driver name.


"Avoiding compound data in software and system design"


  • use a singleton object

    The current API for DBIx::DBH::Legacy requires passing in the connection data hash to each API function. The data hash should be bound to a singleton object and all methods should resource it.

    A good set of Moose roles inspired by MooseX::Role::DBIx::Connector or DBIx::Roles might be in order.

  • use DBIx::Connector

    DBIx::Connector is an excellent module for reusing DBI database connections. This module should optionally connect to DBI via that instead of directly.

  • expose parm validation info:

     > It would be nice if the parameter validation info was exposed in some 
     > way, so that an interactive piece of software can ask a user which 
     > driver they want, then query your module for a list of supported 
     > parameters, then ask the user to fill them in. (Perhaps move the hash 
     > of validation parameters to a new method named valid_params, and then 
     > have connect_data call that method and pass the return value to 
     > validate?)


Terrence Brannon, <>

Sybase support contributed by Rachel Richard.

Mark Stosberg did all of the following:

  • contributed Sqlite support

  • fixed a documentation bug

  • made DBIx::DBH::Legacy more scaleable

    Says Mark: "Just as DBI needs no modifications for a new driver to work, neither should this module.

    I've attached a patch which refactors the code to address this.

    Rather than relying on a hardcoded list, it tries to 'require' the driver, or dies with a related error message.

    This could lower your own maintenance effort, as others can publish additional drivers directly without requiring a new release of DBIx::DBH::Legacy for it to work."

Substantial suggestions by M. Simon Ryan Cavaletto.



Copyright (C) by Terrence Brannon

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.4 or, at your option, any later version of Perl 5 you may have available.

3 POD Errors

The following errors were encountered while parsing the POD:

Around line 204:

You forgot a '=back' before '=head3'

Around line 285:

=back without =over

Around line 339:

You forgot a '=back' before '=head1'