[DB-SIG] Abstraction layer confusion, ULA (was Re: Database Abstraction in Python)

[Tom Haddon]

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