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 ;)
Cheers
--
Jens Rehsack
rehs...@gmail.com
