Re: RFI: Database URIs

On Nov 25, 2013, at 11:02 PM, Jens Rehsack <[email protected]> wrote:

>>   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.

Actually, I take that back. I am only focused on having a URI format for the DSN, not the attribute hash --- at least for now. So I would revise that URI to just "dbi:csv:". Unless SQLEngine was modified to support additional parameters in the DSN, all the other stuff would have to be passed via the attribute hash.

> You can’t - this is a clear point in DBI::DBD::SqlEngine at the moment.

Is that something that might change in the future? I tend to think of the DSN parts as being specific to a connection and specifiable by an end user --- such as the database name, server, username, password, etc. I tend to think of the attribute hash as for the developer, such as transaction and error handling. They are also more specific to the language -- I don't need a PrintError option in my Java app; it has some other API.

> 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.

I don't know if I want the DBI to support it or not. I would like to get feedback on how best to represent database connection information in URIs, and what I might be overlooking. I am not sure what to do about attribute hashes, and so am ignoring them for now.

>> 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.

Well, that's just a matter of how you define that. Maybe "foo" is the name of the directory holding CSV files, and the file names are table names. I realize this is not how DBD::CSV currently works, just pointing out that these things are a matter of definition and implementation.

> 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 ;)

I don't intend to support any drivers at all. I want to define a common URI standard for connecting to database engines without regard to any programming language or API at all.

Best,

David