Re: DBURL name scheme
On Tue, 30 Nov 2004, Tim Bunce wrote: If you're trying to create a wider standard with support in vendor tools then best to come back when there's wider support and some implementations existing. Good idea. I'll do that. Alternatively write a DBI subclass to do-the-right-thing. I could actually just implement the name scheme in my Perl DBI application. That will do for now. ...I'll be back. /hans -- Hamletsgade 4 - 201, DK-2200 København N, Phone: +45 3582 9079 Schou Industries ApS http://schou.dk/CVR: 26 13 44 39 -- De sultne børn i Afrika tænker også på dig -- »Husk mit navn« (anonym)
Re: DBURL name scheme
On Mon, 29 Nov 2004, Hans Schou wrote: But making dbi:// a default prefix will probably restrict the use of DBURL to only DBI. It is not realistic to think that MySQL and PostgreSQL would implement such a naming scheme, where as the original idea might be accepted. Considering that it sounds like you want to embed your DBURL implementation into the DBI interface spec itself, then why is DBI-specificity a problem? The fact that it is built in means they are tied. As for what MySQL and PostgreSQL implement, would not the DBD module for those respective databases be transforming the argument to connect() anyway to meet their database engine's needs? In my opinion, the DBI interface's main job is to define a standardized-as-much-as-possible interface for all DBD drivers to follow, and/or otherwise dispatch to the correct DBD module that can interpret the rest on its own terms. That said ... protocol://[[user[:[EMAIL PROTECTED]:port][/[database[/]]] to dbi://[[user[:[EMAIL PROTECTED]:port]/driver[/[database[/]]] I still support the idea of having the driver-specifying info on the left side of the ://. Essentially, take Hans' format as it is, but interpret protocol to mean the name of the DBD module to use. Aka, put the string that would go in Tim's driver portion and use it as the protocol; to deal with name-space issues, the protocol could look like DBI:foo, such as the first argument to connect() already is. The reason for having the DBMS protocol up front was inspired by: http https ftp news. Here the protocol tells which command and format to send over TCP/IP. As DBI is more like a DBMS-wrapper than a protocol I think it would be logical to people when the DBMS protocol is the prefix. Another issue to consider is that of encoding the individual parts of the URI, in case, for example, the password contains a : or / etc, or if there are differing case-sensitivity issues. Perhaps the format of delimited SQL identifiers could provide an example to follow. -- Darren Duncan
Re: DBURL name scheme
On Mon, 29 Nov 2004, Darren Duncan wrote: On Mon, 29 Nov 2004, Hans Schou wrote: But making dbi:// a default prefix will probably restrict the use of DBURL to only DBI. It is not realistic to think that MySQL and PostgreSQL would implement such a naming scheme, where as the original idea might be accepted. Considering that it sounds like you want to embed your DBURL implementation into the DBI interface spec itself, then why is DBI-specificity a problem? I wanted the syntax to be short. An example: $dbh = DBI-connect(dburl=dbi://localhost/pgsql); $dbh = DBI-connect(dburl=pgsql://localhost); I can see no reason for having dbi:// as DBI would know that a URL will always follow a dburl= If the implementation in DBI would have the syntax: $dbh = DBI-connect(dbi://localhost/pgsql); I could see a reason. But this will only consider DBI, not PostgreSQL, MySQL or Oracle. (Oracle will probably stick to tnsnames.ora anyway) side of the ://. Essentially, take Hans' format as it is, but interpret protocol to mean the name of the DBD module to use. In that way the protocol for PostgreSQL should be 'pg'. $dbh = DBI-connect(dburl=pg://localhost); or the socket version: $dbh = DBI-connect(dburl=pg://); Nice and short. Another issue to consider is that of encoding the individual parts of the URI, in case, for example, the password contains a : or / etc, or if there are differing case-sensitivity issues. Perhaps the format of delimited SQL identifiers could provide an example to follow. Password could have any character except '@'. The rule for http is that these characters ':' and '/' should be represented as %2E and so on. /hans -- Hamletsgade 4 - 201, DK-2200 København N, Phone: +45 3582 9079 Schou Industries ApS http://schou.dk/CVR: 26 13 44 39 -- De sultne børn i Afrika tænker også på dig -- »Husk mit navn« (anonym)
Re: DBURL name scheme
On Mon, 29 Nov 2004, Darren Duncan wrote: Considering that it sounds like you want to embed your DBURL implementation into the DBI interface spec itself, then why is DBI-specificity a problem? Oops, wrong answer before. I want to use DBURL with the command line tools psql and mysql. Konqueror kio could be another application to use. As I am using PostgreSQL my first thought was to have an environment variable called PGURL. But then I thought why not call it DBURL and make it generic. /hans -- Hamletsgade 4 - 201, DK-2200 København N, Phone: +45 3582 9079 Schou Industries ApS http://schou.dk/CVR: 26 13 44 39 -- De sultne børn i Afrika tænker også på dig -- »Husk mit navn« (anonym)
