[DB-SIG] Proposal: model database metadata from JDBC

Dittmar, Daniel daniel.dittmar@sap.com
Mon, 14 Jan 2002 14:40:36 +0100


> From: Federico Di Gregorio [mailto:fog@initd.org]
> i don't want to start a python vs java flame here, but you seem to
> suppose that a java api is good by itself (i myself consider java a

> From: brian zimmer [mailto:bzimmer@ziclix.com]
> I think it would be best to start with the most useful and add 
> as needed.

It was my main intention to implement the stuff once and then forget about
it. That's why I choose a rather largish API. If some consider the stuff in
mxODBC to be mote pythonic, that's fine with me too. It already has two
working implemtations, and as these are ODBC and JDBC wrappers, they can be
used as a reference protocol for the native implementations.

Having a full API would also be a boon to developers of IDEs and development
tools (From Any Todd's mail: "Experience also tells me that getting a common
metadata set is very difficult.") and those mentoring VB and Java refugees
("I can do this in VB. Why can't I do it in Python?")

It might be  good idea to split the interface into two:
- catalog information (tables, columns, procedures etc.)
- database capabilities (identifier format, isolation levels etc.)

The latter is really static and can be generated from a JDBC driver. The
former requires some knowledge of the system tables. Whether the resulting
cursors are passed directly to the application or are filtered into Python
objects isn't that much of a difference for the driver developer.

> From: M.-A. Lemburg [mailto:mal@lemburg.com]
> About the interface: I suppose we could develop a JDBC like
> interface on top of the existing DB API. The class would not
> have to be generated though, but instead get it's information 
> from a passed in connection object.
> 
> Database module wanting to support this interface would then
> have to define a DatabaseMetaData class at module level
> and users could then instantiate it with connection objects.

That was my intent.

The code generator I mentioned is used only:
- to save some typing of the method signatures and the doc strings (and to
get easier updates should we decide on some default parameters or another
doc string format)
- to get the 'database capabilities' automatically from a JDBC driver.


Daniel

-- 
Daniel Dittmar
SAP DB, SAP Labs Berlin
daniel.dittmar@sap.com
http://www.sapdb.org/