On Mon, 6 Dec 2004 17:23:46 +0000, Martyn J. Pearce
<[EMAIL PROTECTED]> wrote:
> On Fri, Dec 03, 2004 at 11:25:53AM +0000, Tim Bunce wrote:
>
>
> > Yes. It's finely balanced though. I can see merit on both sides.
> >
> > The "fill in a form" situation is relatively common. But beyond the
> > "MySQL/Pg model of how servers, ports, databases" work there's also
> > the question of specifying attributes. Taking mysql as an example,
> > specifying mysql_client_found_rows=1 is common (or should be :)
> > and mysql_local_infile=1 can be needed (at least for some versions).
> > Then there's SSL:
> >
> > mysql_ssl=1
> > mysql_ssl_client_key=...
> > mysql_ssl_client_cert=...
> > mysql_ssl_ca_file=...
> > mysql_ssl_ca_path=...
> > mysql_ssl_cipher=...
> >
> > I wouldn't like to be filling in all that on a form. (And there's
> > no need to tell me there are ways to avoid specifying all those
> > through config files, I'm just making a general point here :)
> >
> > I try to make the DBI design hit the "sweet spot" of general utility
> > (while still enabling driver-specific features in a way that's portable).
> > It's clear to me that the DBI hasn't quite hit the sweet spot here.
> >
> > The simplest fix is to standardize one set of driver DSN attribute
> > names so that at least the host, port, and database (schema) can
> > be specified in a portable way.
>
> Is that really the simplest? It occurs that the responses on this thread, and
> in my experience, many people are comfortable & familiar with the use of a
> hash (/ref) for this purpose. If the connect call were to accept a hashref as
> an *alternative* to the current simple string, then there would be no danger
> of backwards-compatibility issues cropping up, and would fit in well with what
> people are already using. That so many people have individually come to the
> same solution suggests that there's something right with it.
>
> my $dbh = DBI->connect({db => 'postgres', dbname => 'foo', port => 6767});
>
> Mx.
>
And this, in fact is what I do at my place too.
my $dbh = connectDBI(driver => 'Oracle', user => 'foo', server =>
'bar', database => 'baz'
RaiseError => 1, PrintError =>0, AutoCommit => 0, driver_special =>
{syb_show_sql =>1, syb_show_eed=>1});
I pull together the various bits in the call (and I support driver =>
oracle too) and just call DBI->connect in the end. Since user defines
tablespace in ORacle, I ignore database-> when driver eq 'Oracle'.
At the top of this thread and at various other entries, the point is
made that many times, the parameters for connection are pulled from a
source that has them listed individually. Why make the
client/programmer synthesize them - let the call do it. Yes? Make it a
requirement of the DBD implementor to take the hashed args and build
the right string and then call connect.
I do it w/o
--
Matthew O. Persico
