Re: RFI: Database URIs
On Nov 25, 2013, at 3:50 AM, Jens Rehsack rehs...@gmail.com wrote: DBI-connect($dsn, $user, $passwd, \%attr) 4th argument is wasted in your current proposal. Er, well, I failed to provide a complete set of examples. Here’s one from the PostgreSQL docs: postgresql://other@localhost/otherdb?connect_timeout=10application_name=myapp All the attributes are provided by the GET query string. Best, David
Re: RFI: Database URIs
Am 25.11.2013 um 18:00 schrieb David E. Wheeler da...@justatheory.com:
On Nov 25, 2013, at 3:50 AM, Jens Rehsack rehs...@gmail.com wrote:
DBI-connect($dsn, $user, $passwd, \%attr)
4th argument is wasted in your current proposal.
Er, well, I failed to provide a complete set of examples. Here’s one from the
PostgreSQL docs:
postgresql://other@localhost/otherdb?connect_timeout=10application_name=myapp
All the attributes are provided by the GET query string.
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.
Cheers
--
Jens Rehsack
rehs...@gmail.com
Re: RFI: Database URIs
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=dataf_dir_search=foof_dir_search=barf_ext=.csv/rf_lock=2f_encoding=utf8csv_eol=%0D%0Acsv_sep_char=,csv_quote_char=%22csv_escape_char=%22csv+class=Text::CSV_XScsv_null=1RaiseError=1PrintError=1FetchHashKeyName=NAME_lccsv_tables=%7B%22info%22%3A%20%7B%22f_file%22%3A%22info_csv%22%7D%7D
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?
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.
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.
* 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
Best,
David
Re: RFI: Database URIs
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=dataf_dir_search=foof_dir_search=barf_ext=.csv/rf_lock=2f_encoding=utf8csv_eol=%0D%0Acsv_sep_char=,csv_quote_char=%22csv_escape_char=%22csv+class=Text::CSV_XScsv_null=1RaiseError=1PrintError=1FetchHashKeyName=NAME_lccsv_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
Re: RFI: Database URIs
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=dataf_dir_search=foof_dir_search=barf_ext=.csv/rf_lock=2f_encoding=utf8csv_eol=%0D%0Acsv_sep_char=,csv_quote_char=%22csv_escape_char=%22csv+class=Text::CSV_XScsv_null=1RaiseError=1PrintError=1FetchHashKeyName=NAME_lccsv_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
