[DB-SIG] Extending DB-API
Ian Bicking
ianb at colorstudy.com
Thu Nov 16 19:59:28 CET 2006
I probably won't have the time to really follow this through, but since
there has been a little discussion of this stuff lately I'd like to
throw out an idea for where I think Python database standards should go.
This mostly builds on the dbapi rather than extending it directly (I
think).
The major things I think we can standardize:
* There's no common way to configure databases. I'd like to see a
single URI syntax that everyone can use. This should be modestly
extensible via query string parameters.
* Given a database connection there should be a well-documented strategy
for discovering the type of the connection (including the server's
version) and loading up code specific to that module and some interface.
This allows compatibility code to be developed separately from the
database connection modules, and separately from consumers like ORMs.
This would also give a clear place to build database introspection
tools, without tying that work to the release schedules or development
process of the current database modules. Realistically those existing
modules are developed fairly slowly and conservatively, and require
skill in things like writing C extensions. Compatibility layers have
none of these qualities.
* Unified exceptions. This can be done currently with monkeypatching
the inheritance hierarchy, but they aren't unified to anything in
particular that you can rely on.
* Figure out a strategy for parameter styles. Maybe this just means a
reasonable way to handle SQL in a more abstract way than as strings with
markers (that way no update is required to the dbapi). Or maybe
something more sophisticated. Or we could even be lazy and use
%s/pyformat, which is the only marker that can be easily translated to
other markers.
* Maybe some work on database connection pooling strategies. Maybe this
can just be library code. I think we need a little more data on the
threading restrictions than dbapi gives (sqlite in particular doesn't
fit into any of the current levels).
From there I see some other useful database standards:
* A standard transaction container. The Zope transaction container is a
reasonable and straight-forward implementation (though it needs to be
better extracted from Zope).
* A standard way to retrieve database configuration and connections.
This way database library/framework code can be written in a reasonably
abstract way without worrying about deployment concerns.
--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the DB-SIG
mailing list