[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.
or
- 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,
Fabien.
More information about the DB-SIG
mailing list