> > That's what DBI wrappers do, and I have one of those too. But my DBI
> > wrapper reads its connection information for each "logical" data source from
> > a hash. Then there's a build_dsn() method that assembles the pieces
> > according to the name of the driver.
> >
> > If each DBD did that for me, I could just pass a reference to my connection
> > info hash directly to DBI->connect() and then remove the build_dsn() code
> > from my wrapper.
>
> Assuming that each DBD used the same names for elements with the same meaning
> (database vs dbname vs db vs sid etc etc).
>
> Tim.
mandating a new method for all compliand DBDs is, as ever, outrageeous.
Here's a proposed compromise: A new DBD that takes the elements of
the attributes hash, and at connect time this DBD will build the DSN (or
croak and complain explicitly about what is missing in a well defined way)
and return a real $dbh resulting from calling DBI->connect with the build DSN.
DBI doc tells us:
$dbh = DBI->connect($dsn, $user, $password,
{ RaiseError => 1, AutoCommit => 0 });
DBD::dsn (DBD::any? DBD::DBH?) would work like this:
$dbh = DBI->connect('DBI:DBH', $user, $password,
{ RaiseError => 1, AutoCommit => 0,
host => $dbhost, dbd => 'pg', port => $dbport });
That way, DBI->connect doesn't need to be rewritten to allow a hash -- it
already allows the %attr hash -- and the intermediate DSN created by
the build_dsn method is hidden away in the inner workings.
Am I missing something?
