[DB-SIG] Abstraction layer confusion,
ULA (was Re: Database Abstraction in Python)
Tom Haddon
thaddon at equilar.com
Mon Apr 18 20:08:19 CEST 2005
Hi James,
I like a lot of the features you discuss, but have two concerns that I'm hoping to understand better:
- As I understand it there is "metadata" that is needed to perform the abstraction in web.database and this is stored in the database itself. I'd also read somewhere that if you make some data changes to directly on the database that it might cause issues for web.database. This seems to me like a potential problem if it's true, as you're losing the ability to manipulate the database outside of the application for which it was written.
- Just wondering about it's relationship to the web module. Is it really part of/dependant on the rest of the web module, or is it more accurately a separate database module? My preference would be separate as otherwise it seems like the implication is that it's only applicable for/suitable for web applications.
Thanks, Tom
-----Original Message-----
From: db-sig-bounces at python.org [mailto:db-sig-bounces at python.org]On
Behalf Of James Gardner
Sent: Monday, April 18, 2005 10:53 AM
To: db-sig at python.org
Subject: Re: [DB-SIG] Abstraction layer confusion,ULA (was Re: Database
Abstraction in Python)
Hi All,
In developing PDBC (the web.database module) I decided there were 5
levels of database abstraction so perhaps we can agree on naming them
like this:
Driver
DB-API
User Level API
Portability Layer
Object Relational Mapper
The driver is whatever libraries are used to connect to the database at
the lowest level. The DB-API 2.0 wraps the driver functionality to allow
low level database access for full control via SQL (perhaps with some
sensible type conversions). The user level API wraps up the DB-API
functionality into an easier to use form but doesn't abstract the
database functionality, only the API. The portability layer provides
database abstraction in both SQL and type conversions so that code works
identically on all supported databases. The object relational mapper
maps Python objects to SQL relationships so that no SQL is necessarily
needed.
To the best of my knowledge PDO, PyDAL, adodb are what I would describe
as user level APIs that is they simply wrap the DB-API methods in a more
convenient and standard form. SQLObject is an Object Relational Mapper.
The only portability layer I know of is my own. That is, an API that
behaves EXACTLY the same with EXACTLY the same SQL commands on all
supported databases by making a compromise between features and
portability (regardless of whether we agree this is actually the best
approach!)
It sounds like what is needed then is a DB-API with slightly less
flexibility left to the implementor which takes into account any changes
like the adoption of the datetime module and perhaps support for a
reduced number of parameter types, tighter use of connection parameters
etc. Are we also agreeing we need a user level API, perhaps similar to
PDO to be included as part of the standard library?? If so, would we
also include the database drivers themselves to provide database
functionality out of the box? Is there no general desire to work on a
portability layer or object relational mapper to be included in the
standard library?
Cheers,
James
_______________________________________________
DB-SIG maillist - DB-SIG at python.org
http://mail.python.org/mailman/listinfo/db-sig
More information about the DB-SIG
mailing list