[DB-SIG] How to know what to do with parameters...

[Kevin Jacobs]

On Fri, 16 May 2003, Chris Cogdon wrote:
> On Friday, May 16, 2003, at 10:29 US/Pacific, Kevin Jacobs wrote:
> > The _dbapi_type is fine, although it is of little use by itself.  The
> > _dbapi_value is the part that I have deep misgivings about.  Are we 
> > going to
> > define canonical string representations for every possible database 
> > type for
> > all possible backends as part of DB-API?
> 
> I think this highlights one of the classical interface problems.
> 
> - If we put the intelligence into the API, then it won't necessarily 
> support new data types created by the application writer.
> - If we put the intelligence into the data types, then it won't 
> necessarily support differing backends[1]

The first choice isn't as bad as it sounds, except when one tries to cram it
all into DB-API.  My own database abstraction interface can be roughly
factored into four layers (from highest to lowest degree of abstraction).

 1a) High level query, transaction, and error handling interfaces
 2)  SQL dialect translation, schema reflection, and high level data-type
     mapping layer
 3)  Backend abstraction layer (e.g., PostgreSQL, MS-SQL, Sybase, Oracle, 
     SAPDB, etc.)
 4)  Backend low level drivers (basically DB-API drivers)

In addition these are other systems for high level connection description
(DSNs), connection management (pooling), query profiling, logging,
debugging, and data manipulation.

So my major concern is on how to get the DB-API to expose more of the
database capabilities, and not to make them do black magic data conversions.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs at theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com