[DB-SIG] URI syntax for databases

Ian Bicking ianb at colorstudy.com
Wed Mar 30 21:41:25 CEST 2005


What do people think about standardizing on a URI syntax for connecting 
to databases?  It makes it much easier to configure databases from my 
experience, and helps unify the different signatures of connect().  In 
SQLObject we've been using:

module_name://user:password@hostname:port/database_name?other_parameters

except database names instead of module names, like firebird: instead of 
kinterbasdb:, and pgsql: instead of psycopg:, but maybe that could 
change.  Or modules could provide aliases... though that would make it 
harder, since it's harder to detect aliases.  Maybe the URI could be 
translated to:

mod = __import__(uri.split(':')[0])
conn = mod.uri_connection(uri)

Some databases are different, like sqlite:/path_to_db_file, but they 
pretty much all fit into the pattern.  SQLite in-memory databases are 
weird, since you connect to ':memory:', and there's all the 
Windows-path-as-URI issues, but this is exactly the sort of thing where 
a small spec could give consistency.

Also parameters end up all being strings, so you have to coerce them if 
you want booleans or some other value -- usually this is fairly easy to 
figure out, but it should be moved to the URI translation.

It also occurs to me that it would be nice to parse the connection 
string without actually making a connection -- i.e., produce (factory, 
args, kwargs), like (psycopg.connect, ('dsn=...',), {}).


My particular desire here is I want a database backend for a web 
sessions, and that database has to be configurable, and a URI is the 
nicest way to configure it.  But I want to write it to the DB-API, not 
SQLObject, so pushing that standard up the stack would be nice.  I could 
factor this out of SQLObject right now, but ultimately it would be 
better if database drivers included the parsing code in their own packages.

Thoughts?

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the DB-SIG mailing list