[DB-SIG] Re: [Python-Dev] Toward Python's future article

Jonathan M. Franz jfranz at neurokode.com
Sat Oct 9 08:28:12 CEST 2004


[MAL]
>>/ I wouldn't want to make it a requirement, though, since the DB API
/>>/ is defined in terms of API signatures, not specific objects, e.g. a
/>>/ module author should have the freedom to continue to use e.g. mxDateTime,
/>>/ tuples or strings or leave the choice of data type to the users.
/[GvR]
>Well, that's exactly what I'm hoping to get rid of in the future. By
>prescribing the use of datetime (for results -- it may remain optional
>for input values), we implicitly support a much larger set of API
>signatures for those results that users can depend on. Right now, if
>you want to do anything useful with a result representing a timestamp,
>you have to turn it into some other date/time object first whose API
>you know.

I agree with GvR: I think others do as well.  I even think there was a
grant proposal that mentioned this issue.  *wink*

It is a change that will break things - but if it makes the end-users 
lives easier, I'm for it.  Then again, I'm biased (having written the 
grant proposal and such).

[MAL]
>>/ JDBC is more like an OO-wrapper on top of the low-level API defined
/>>/ by the DB API.
/[GvR]
>I dunno.The db-API is pretty OO itself, and many of the db-API
>interfaces feel higher-level than corresponding things in JDBC. I just
>*love* how easy it is in Python to open a database, create a cursor,
>execute a SELECT and retrieve the results. JDBC requires much more
>work.

Jython improves on the usability of JDBC alot, but it is (like most 
Java APIs) still very verbose.  Java in general just requires too much
boilerplate code.

[MAL]
>>/ As I've mentioned quite a few times on this list, it is well
/>>/ possible to write an abstraction layer on top of the existing
/>>/ database modules that exposes a JDBC-like API or a uniform
/>>/ DB-API 2.0 like interface (e.g. http://sourceforge.net/projects/pydal/)
/>>/ given a set of DB-API 2.0 compatible database drivers.
/[GvR]
>Maybe the latter is the way to go. Although I still think it's a shame
>we need it at all, given how much the db-API alrady gets right.

I think a driver/user-api split is, although painful, the way to go.
Perl, JDBC, ADO and others all do this.  That said, there are things 
missing in the 'driver layer' that (as a maintainer of a wrapper 
module) would be exceedingly useful.  Catalog inspection comes to mind -
 hiding the SQL (if any) used by the DB to get the list of 
databases/tables/columns.

[MAL]
>>/ Think of the DB API as a driver interface specification to make
/>>/ a module compatible to such a more abstract database manager.
/>>/ 
/>>/ A specification of such a database manager interface is something
/>>/ that can well be done without requiring all database modules to
/>>/ implement the complete (and possibly complicated) set of features.
/>>/ 
/>>/ The whole point of the DB API spec is to make things easy for the
/>>/ database module author, so anything which goes beyond the low-level
/>>/ nature of this interface should be left to a separate specification.

//I think co-operation in this case would be beneficial to both 'sides'.

//I agree that we shouldn't make life _too_ hard for the driver creators,
but some give-and-take would need to exist between such a 
database-manager-interface group and the driver spec (DBAPI).

In my grant proposal, I called this layer the 'user layer'.

Example 1: Type listing in the driver/DBAPI module.  
Some modules support the basic types in the standard, others extend 
them with more specific types such as LOB (cx_Oracle) - while dir() 
and documentation is useful to find these for a human, the 
'user layer'(wrapper) needs to either support just the minimum types 
(which may break things when a query is executed), or know about all 
the types in the driver/DBAPI module ahead of time.

These type issues come into play when implementing things such as
 editable resultsets/records (one of the finest features of ADO).

Some hints and/or changes might be needed at the underlying 
DBAPI/driver layer to support this higher-level feature without 
severe limitations/kludgyness (as I have experienced firsthand).

My list of possible extensions is long - some have been discussed 
here before - but not much movement has been made forward.  

/Anyway - my point is - we'll have to work on the driver/DBAPI spec 
as well as the user-layer as a whole to get a truly usable and 
better system.  Switching to datetime types is just a start, IMHO.


[GvR]
>Sure, but that's putting the db implementer's convenience well ahead
>of the user's convenience. At some point, those db implementers that
>put the user's convenience first will gain the upper hand (as the
>demise of DCOracle in favor of cx_Oracle has shown).

Unless a standard set of extensions, or a new higher-level standard 
is defined, the extensions some modules provide could hamper the 
overall acceptance/usage of the system.  And, for those writing the 
user-layer, such extensions can be a big pain - do you write a 
specific exception to expose the feature of this single module 
- or do you ignore it?

I think the community should work together on this to move things
forward in such a way that the user's convenience is kept in mind,
but we don't burden the module authors too much - and that the 
provided conveniences are available to users of all RDBMs, not just
a subset.

And yes, once again, I have made an overly verbose post :)

~Jon Franz
NeuroKode Labs, LLC



More information about the DB-SIG mailing list