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:[EMAIL PROTECTED]: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 ! ::::
_______________________________________________
DB-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/db-sig
