[DB-SIG] URI syntax for databases

[M.-A. Lemburg]

Ian Bicking wrote:
> 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?

This doesn't strike me as very Pythonic. The DB API spec specifies a
set of keyword parameters that cover most usage scenarios already:

         As a guideline the connection constructor parameters should be
         implemented as keyword parameters for more intuitive use and
         follow this order of parameters:

         dsn         Data source name as string
         user        User name as string (optional)
         password    Password as string (optional)
         host        Hostname (optional)
         database    Database name (optional)

         E.g. a connect could look like this:

         connect(dsn='myhost:MYDB',user='guido',password='234$')

Your syntax seems to be more geared torwards an abstract
interface to databases, which is - as you say - one level
above the DB API spec.

It should be rather simple to write a factory function which
takes your syntax and then imports the right module, translates
the parameters and connects to the database.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 30 2005)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::