[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
>>/ 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.
>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
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).
>>/ JDBC is more like an OO-wrapper on top of the low-level API defined
/>>/ by the DB API.
>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
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
>>/ 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.
>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
>>/ 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.
>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
And yes, once again, I have made an overly verbose post :)
NeuroKode Labs, LLC
More information about the DB-SIG