Re: Proposing an API for the extension for simplifying database connections
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?
Proposing an API for the extension for simplifying database connections
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?
Re: Proposing an API for the extension for simplifying database connections
On Thu, 13 Jan 2005 00:40:49 -0600, David Nicol [EMAIL PROTECTED] wrote: Am I missing something? Yes, to convince, at least me. I still don't understand, what this should be good for. If it is fine for you, with a limited number of drivers supported, then you may very well use it. You may as well write a DBIx extension or do whatever you want. For example, this could easily be implemented as a DBI subclass with a slightly different connect method. However, in general, the DBI is based on the DSN as a string with almost no syntactical rules. Drivers have used this liberty, with good reasons. Why leave this at all? Jochen -- Sum. Cogitone?
