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.
