Of course, following that pattern you could get dbapi:jdbc:postgresql://... which feels awfully weird to me.
a) I'd prefer pydbapi: as a prefix. That way, someone looking at a configuration file could at least get the notion that any problems might be related to some Python lib.
I guess... blah, feels like the namespacitus problem of Java, though.
b) Using a module path instead of a DBMS product name is generally
preferable (and seemed to be the consent so far). With the JDBC scheme,
all relevant drivers have to be loaded into memory first, the diver
manager then asks each if the driver would accept a specific URI.
Yes, it's certainly a problem. For most the module name isn't that bad, though explaining why you have to use MySQLdb: instead of mysql: will be a little annoying, and certainly unsatisfying to the user. I'd feel compelled to create a mapping of aliases, even if I fell back on the module name.
There exists the possibility of centrally registering aliases, that is short of importing modules and having them self-register. E.g. put a "db-api-aliases" directory somewhere on sys.path, with filenames like "mysql.txt" that contains "MySQLdb". Maybe multiple lines in a file if there are multiple implementors (and the connector can either bail with a helpful error message about options for being more explicit, or can prefer one driver over another).
c) Should username and password be used similar to other protocols? pydbapi:<modulepath>://[<username>:<password>@]<host>[: <port>/
That was my expectation. Any parameters could also be interpreted as well, like ?autocommit=t&datestyle=mxDateTime -- and so on, which leaves room for any parameters that would be useful.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig
