On Nov 25, 2013, at 11:21 PM, H.Merijn Brand <[email protected]> wrote:
> As I always use 2. when writing scripts, mostly because I use quite a
> few useful attributes in the 4th argument already, it is the most
> logical place: easy to maintain, easy to read and easy to extend.
Also very much specific to the DBI and DBDs, and a useful place for you as the
developer to define how the DBI should interface with the database.
> One of the huge disadvantages of putting everything in the DSN is the
> you have to rethink if and when character like :, ;, ", and ' should be
> escaped and how and that values like undef are pretty darn impossible
> (unless the driver has taken the trouble to support that).
And as far as I can tell, the DBI does not currently support any escaping at
all in the DSN. I created a database with a comma in its name, and was unable
to figure out how to get the DBI to connect to it.
> The first method however has a big advantage when the script (or a
> one-liner) is completely driven by environment settings.
>
> my $dbh = DBI->connect ($ENV{DBI_DSN});
>
> which happens to be the (underdocumented) default for connect and thus
> equivalent to
>
> my $dbh = DBI->connect;
I dislike this, personally. As a developer, I *always* exercise a certain
amount of control over what gets passed in the attribute hash. It would be a
rare condition where I would want to let an end-user do it. A multi-database
command-line tool like dbish would be one of those rare exceptions.
Best,
David
