[DB-SIG] Getting schemas and other niceties

Fabien COUTANT fcoutant at freesurf.fr
Sun Jul 20 10:28:09 EDT 2003

On Saturday, 19 July 2003, you (Kevin Jacobs) wrote:

> > - ODBC, its API and your document are copyrighted material (respectively by
> >     MS and egenix), so we must invent DB-API's own naming and
> >     representation of meta-data.
> No -- just our own documentation that may also point at mxODBC and MS ODBC. 
> However, we may choose to deviate from these anyway, since Python is more
> expressive about certain concepts than the C ODBC and the Java JDBC APIs.

Why link/attach to an external specification source, that is commercial and
independant of DBSIG ?  If we are to do that, I prefer we refer to some JDBC
version which would be more stable (in location notably ;-).  In fact it
may even be a better thing to attach the referred spec document to DB-API
spec so that there are no more location problems possible.

> > - SQL-level representation should be returned (such as the already declared
> >     type codes used in cursors description attribute) instead of byte
> This is a dangerously ambiguous statement.  What I _think_ you mean is that
> you want canonical representations (not SQL representations) instead of
> RDBMS-native binary values.  What you do not want are SQL literal
> representations, at least not by default.

Yes, exactly.  I want types returned as driver.STRING, driver.BINARY,
driver.NUMBER etc.

> > - columns in result sets corresponding to features of standard SQL (column
> >     name, type, size, unique, nullable, ...) should be made first and
> First and mandatory?  Why enforce an ordinal relationship among attributes
> of a given column?  The existing description tuple concept is simply
> outdated and needs to be replaced, not kludged with extensions.

To be useful there must be a way to find back precise columns (e.g. column
name).  I simply suggested an idea that was uniform with the existing
DB-API cursor description attribute.  Alternatively, since we are speaking
of a extension that does not collide with existing spec, we could choose
a new mechanism to point columns in result sets, such as:
- fixing once and for all mandatory column names.  E.g. "COLUMN_NAME" when
    retrieving list of columns.
- setting a member attribute of driver/connection with the position or name
    of the column in the result set.  E.g. db.COLUMN_NAME == 3 (this is an
    example, of course we should not let the choice open as to whether
    these are names or positions)

> My wish list includes a structured schema introspection API that does not
> intrude with the interface of cursor and connection objects.  i.e., I'd like
> to see a connection.schema property of method, but not a multitude of new
> methods added to the connection and cursor interfaces.

Agreed.  Again this is going towards JDBC's API, whereby there is a
getMetaData() method on connection, which returns a DatabaseMetaData object
that holds all other meta-info methods and attributes.

Hope this helps,

More information about the DB-SIG mailing list