Perhaps it would be a good idea to list the high level constructs:
fetchrow_hashref (from Perl):
returning a mapping from column names to
values instead of a tuple
implementable through proxy classes: YES
my take: how about a callable object which acts like
a filter for every row. This would allow a lot of
other neat stuff like creating a Python object
from a row or fetching detail information for a
master row
scrollable cursors (ODBC, JDBC):
implementable through proxy classes: NO, unless you
don't mind having the whole result set in memory
updatable cursors (ODBC, JDBC):
implementable through proxy classes: NO
meta data (ODBC, JDBC):
implementable on top of DB API: YES, but
the code would be database specific
my take: instead of copying either
ODBC or JDBC, I would now prefer something
like http://dbdoc.sourceforge.net/ (see:
simple Python API for inspecting DB schemas),
cursors are just too clumsy for this kind of data
runtime checks for DB API conformance:
implementable through proxy classes: YES
my take: as a driver author, I really resent
- disabling features of the database
- writing complex checks for stuff that
won't do any harm (example from JDBC:
parsing SQL commands so that no SELECT
gets through an executeUpdate)
I could imagine that there will exist
multiple check proxies to go with the most
common sets of porting targets, say one
checker for PostgreSQL + MySQL, one for
Oracle + DB2 + SAP DB, etc...
common data type handling:
DATE/TIME, BLOBs, fixed decimal
common SQL lexer:
- parameter style
- SQL identifier (quote, case sensitivity)
- literals
common SQL syntax:
No, JDBC or DBI don't provide this
either.
--
Daniel Dittmar
SAP DB, SAP Labs Berlin
daniel.dittmar@sap.com
http://www.sapdb.org/