On Tue, 26 Nov 2013 08:02:45 +0100, Jens Rehsack <rehs...@gmail.com>
wrote:
>
> Am 25.11.2013 um 20:42 schrieb David E. Wheeler <da...@justatheory.com>:
>
> > On Nov 25, 2013, at 11:08 AM, Jens Rehsack <rehs...@gmail.com> wrote:
> >
> >> Let’s go - shoot:
> >>
> >> # specify most possible flags via driver flags
> >> $dbh = DBI->connect ("dbi:CSV:", undef, undef, {
> >> f_schema => undef,
> >> f_dir => "data",
> >> f_dir_search => [],
> >> f_ext => ".csv/r",
> >> f_lock => 2,
> >> f_encoding => "utf8",
> >>
> >> csv_eol => "\r\n",
> >> csv_sep_char => ",",
> >> csv_quote_char => '"',
> >> csv_escape_char => '"',
> >> csv_class => "Text::CSV_XS",
> >> csv_null => 1,
> >> csv_tables => {
> >> info => { f_file => "info.csv" }
> >> },
> >>
> >> RaiseError => 1,
> >> PrintError => 1,
> >> FetchHashKeyName => "NAME_lc",
> >> }) or die $DBI::errstr;
> >>
> >> And keep in mind, csv_tables can be more complex and there’re other
> >> attributes like it eg. in DBD::AnyData.
> >
> > Well, how you would want to handle params would be up to you. No, they are
> > not great for hashes, but do-able.
> >
> >
> > db:csv?f_dir=data&f_dir_search=foo&f_dir_search=bar&f_ext=.csv/r&f_lock=2&f_encoding=utf8&csv_eol=%0D%0A&csv_sep_char=,&csv_quote_char=%22&csv_escape_char=%22&csv+class=Text::CSV_XS&csv_null=1&RaiseError=1&PrintError=1&FetchHashKeyName=NAME_lc&csv_tables=%7B%22info%22%3A%20%7B%22f_file%22%3A%22info_csv%22%7D%7D
>
> Happy hacking, when you want type that on command line. DBD::CSV (and other
> Pure-Perl drivers) is designed for flexibility and quick setup, not for
> expensive configuration and long-term running.
>
> > So yeah, one would need to do some sort of parsting of nested data (JSON in
> > the csv_tables example here), though arrays work okay (e.g., f_dir_search).
> >
> > OTOH, can you specify all this stuff in a DSN parseable by parse_dsn(),
> > either?
>
> You can’t - this is a clear point in DBI::DBD::SqlEngine at the moment.
>
> > But my point is not to replace the connect() API, but to create a standard
> > of sorts for representing connection info in a URL, to make it easier to
> > specify how to connect to things on the command-line. Yeah, if you want to
> > do everything, it will require more work, but that would be up to the code
> > that handles each driver, which is to say the URI subclass for a particular
> > DBMS.
>
> All I say to you: if you want DBI supporting that - keep in mind the
> whole requirements. If you just want to do another DBI extension, with
> limited coverage and usage - feel free.
>
> > But this discussion orthogonal to my original questions, which were:
> >
> > * Should I use a hierarchical scheme like JDBC? I’m leaning heavily toward
> > this now, just need a decent prefix, I'm thinking "dbms", e.g.,
> > "dbms:csv:foo“.
>
> You can’t - because there is no „foo“ database for DBD::CSV at the moment.
> Conceptual issue. In current state of development, those pure-perl DBMS
> simulating drivers have no persistent metadata as mysql and postgresql have.
>
> > * Do I have the metadata wrong for any of the DBMSes I have so far added
> > support for? Right now that’s just the ports they listen on by default:
> >
> > https://github.com/theory/uri-db/blob/master/t/db.t#L9
>
> I think you miss my point - I don’t say that you’re wrong, I say you
> lack a lot of requirements. When you don’t intend to support those
> pure-perl drivers, you’re fine and please go ahead. When you intend
> full DBI driver support, DBDI (https://github.com/timbunce/DBDI) could
> enlighten you. Following that concept would allow you a migration to p6
> one fine day ;)
You are both right
ATM there are two ways to "define" the DSN:
1. Using DSN
my $dbh = DBI->connect ("dbi:Pg:dbname=foo;…");
2. Using driver + attributes
my $dbh = DBI->connect ("dbi:Pg:", $u, $p, { dbname => "foo", … });
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.
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).
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 don't know if having yet another way to define the DSN is going to
add a lot of trouble or a lot of pleasure. What I *do* know is that if
this will catch on, the DSN parts in DBI - including the docs - will be
better tested :)
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.19 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
