On Nov 25, 2013, at 11:02 PM, Jens Rehsack <rehs...@gmail.com> 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
