On Tue, Nov 30, 2004 at 10:40:34PM +0000, Nicholas Clark wrote:
> On Tue, Nov 30, 2004 at 10:32:12PM +0000, Tim Bunce wrote:
> > On Tue, Nov 30, 2004 at 09:38:47PM +0000, Nicholas Clark wrote:
> > > On Tue, Nov 30, 2004 at 08:53:51PM +0000, Tim Bunce wrote:
>
> > > 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?
>
> Oops. 1 more line would have helped. This precedes my previous code:
>
> my $dsn = "$dbspec->{driver}:$dbspec->{db_name}:$dbspec->{domain}";
>
> Even if I keep the DSN in a flat string, I have to remember that MySQL
> wants driver:DBname:hostname:port=# while Pg wants
> driver:dbname:host=name;port=#
>
> and to me needing to remember all this trivia seems wasteful.
>
> It doesn't actually matter if its in a hash or flat string, there's too much
> driver specific already even in the simple bits I would like flexibility in.
>
> In general I find that a hash ref is useful as an argument to a function as
> it provides named parameters, which avoids needing to remember a list order
> for parameters, and also to have to fill in defaults to make the list up to
> the position of the parameter you wish to change.
>
> I guess I don't find it natural thinking about parameters as a single string.
Do you generally pass URLs around as a string or broken up into a hash?
Tim.
