Feel free to create a DBD::DBH or somesuch.
Tim.
p.s. Best not to cross-post dbi-users and dbi-dev. This sort of 'requirements
spec'
discussion is best on dbi-users as "they" would be your "customers".
On Thu, Jan 13, 2005 at 12:40:49AM -0600, David Nicol wrote:
> > > 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?
