Re: DBIx::DBH - Perl extension for simplifying database connections
On Tue, Nov 30, 2004 at 11:02:31PM -0600, David Nicol wrote: instead of having to haul around the code to figure this out, why not create a handy documentary web service somewhere where you fill out the blanks and get an appropriate connection string? Loading a module every time you start the program just to create something that is a permanent per-installation configuration constant strikes me has if not ugly, at least hideously post-modern. I'll even donate a spot of server space to the cause if you don't have it already. It's a kind offer, but does your server reach me when I'm working offline? Doubtful. But I have a local CPAN mirror, and run local database servers for development. Nicholas Clark
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
Tim Bunce wrote on 30 November 2004 23:32
On Tue, Nov 30, 2004 at 09:38:47PM +, Nicholas Clark wrote:
On Tue, Nov 30, 2004 at 08:53:51PM +, Tim Bunce wrote:
I don't get it. Can someone give me some small but real examples
of the problem that's being solved here?
The one that I've hit - specifying port and host, Pg vs
Mysql (and SQlite):
if ($dbspec-{driver} eq 'DBI:Pg') {
# Aaargh. Why aren't these things standarised?
$dsn = DBI:Pg:host=$dbspec-{domain};
# Aargh. W.T.F. is this case sensitivity here? It fails
to connect unless
# the name is all lowercase (as is stored within the
non-case preserving
# pg DB)
$dsn .= lc ;dbname=$dbspec-{db_name} if length
$dbspec-{db_name};
$dsn .= ;port=$dbspec-{port} if defined $dbspec-{port};
} else {
$dsn .= :port=$dbspec-{port} if defined $dbspec-{port};
}
It seems to me that the problem is of your own making.
Why have separate hash elements for all these things in the
first place?
In my case because if I connect to the same database from two different
servers with two different versions of Sybase Open Client then DBD::Sybase
and the underlying drivers need connection strings that are totally
different (and not at all intuitive IMO) but contain basically the same
data. Thus I have an ini file that contains the appropriate info along with
a special entry that determines which style to use. Now only one thing needs
to be changed between the two machines.
This is part of the code that handles building the connection string from
the ini file:
if (lc($style) eq short) {
$fmt=DRIVER={%s};UID=%s;PWD=%s;SRVR=%s;DB=%s;
@args=qw(driver username password server dbname);
} elsif (lc($style) eq long) {
$fmt=DRIVER={%s};UID=%s;PWD=%s;NLN=%s;NA=%s;DB=%s;
@args=qw(driver username password protocol server dbname);
And here is what the inifile looks like:
[dsn]
; this is the setting for GOBS01 PRODUCTION
style= short
driver = Sybase ASE ODBC Driver
username = him_or_me
password = uhuh
server = that_server_there
dbname = funky_db
protocol = blahblah
Now if we used two connection strings we have all of that data duplicated in
the two strings, which as we all know is a scenario just crying out for
refactoring. We in fact did do this for some time, but it was always falling
out of synch when the data needed to change and the ops folks were forever
changing the wrong string.
Ive got other examples of this. If you use DBD::ODBC you need an entirely
different connection string than when using the faster and better
DBD::Sybase which has as I already mentioned different requirements
depending on local features. Since we had some weird compatibilitiy issue
with Sybase Open Client for a while in some places our code had to fallback
to using DBD::ODBC when DBD::Sybase diver was unavailable, resulting in even
more connection string variants.
IMO the idea of this module is great and frankly resolves something that ive
heard many a folk (here and elsewhere) bitch about being one of DBI's few
annoyances. (That and $dbh-selectall_arrayref($query,{Slice={}}) ;-)
I will say that I agree entirely with those who argue that DBIx::DBH is a
bad name. IMO DBI itself should have a more transparent way of handling this
so an additional module is not required. Surely there is base information
that pretty well all serious DB's will require to open a connection so
mandating a driver agnostic interface to providing those details and then
letting the driver do the rest would seem to make sense.
Yves
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 09:46:24AM +, Tim Bunce wrote: Do you generally pass URLs around as a string or broken up into a hash? If I have to deal with query strings in Perl, I do prefer to deal with them as hash, and then use CGI.pm to re-stringify it for me as needed. Mark
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, Dec 01, 2004 at 09:56:01AM -0500, John Siracusa wrote: On Wed, 1 Dec 2004 09:46:24 +, Tim Bunce [EMAIL PROTECTED] wrote: Do you generally pass URLs around as a string or broken up into a hash? If they had different formats for different consumers, I would. (And even today, I use my own URI objects when I know I'll have to do any significant amount of manipulation.) I think this module is definitely useful. I already store my DSNs in hashes and assemble the pieces as necessary depending on the driver. Lots of people do, it seems, but I'm not getting much background about why. FWIW, the reason I'm digging here is because I agree there may be some value in the DBI supporting something along these lines, but I need a better understanding of the underlying issues. More real- world examples would help. It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. Tim.
RE: DBIx::DBH - Perl extension for simplifying database connectio ns
It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. Duplication of data in multiple places is the answer I think. The more DSN strings you have the more needs to be changed later on, and the bigger the chance that those changes include errors. Having a single transparent interface would reduce that error (and the frustration associated with it) Cheers, Yves
Re: DBIx::DBH - Perl extension for simplifying database connections
On Wed, 1 Dec 2004 18:39:00 +, Tim Bunce [EMAIL PROTECTED] wrote: FWIW, the reason I'm digging here is because I agree there may be some value in the DBI supporting something along these lines, but I need a better understanding of the underlying issues. More real- world examples would help. It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. I like to be able to get at the pieces in isolation. Sometimes I want to know the driver name, for example, without having to actually connect. I also like to be able to switch the database type by just changing the driver name. Looking up the DSN format is annoying. So I do it once and put it in a module. Then I just deal with the pieces without caring how they have to be assembled for a particular database. Heck, I no longer even know all the various DSN formats for the database types I deal with...and I like it that way :) -John
Re: DBIx::DBH - Perl extension for simplifying database connectio ns
On Wed, Dec 01, 2004 at 06:43:51PM -, Orton, Yves wrote: It'll always come down to the issue of why not store complete DSNs? and so far that's not been well covered by the feedback I've got. Duplication of data in multiple places is the answer I think. The more DSN strings you have the more needs to be changed later on, and the bigger the chance that those changes include errors. Having a single transparent interface would reduce that error (and the frustration associated with it) Can you modify the example you gave earlier to show how you'd use DBIx::DBH (or whatever it's called :) to do the same thing? Tim.
