[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