[DB-SIG] Getting schemas and other niceties

[Kevin Jacobs]

On Sat, 19 Jul 2003, Fabien COUTANT wrote:
> I'm ok for the concept, but I see a few things that should be taken into
> account to accomplish integration into DB-API:
> 
> - 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.

> - SQL-level representation should be returned (such as the already declared
>     type codes used in cursors description attribute) instead of byte
>     streams or DB/ODBC specific codes.
>     This does not prevent specific types to be added, I just mean standard
>     "codes" must be used for standard types.

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.

> - columns in result sets corresponding to features of standard SQL (column
>     name, type, size, unique, nullable, ...) should be made first and
>     mandatory (but would allow for None values in some specified columns,
>     as a provision for DBMS that don't support the feature).  We have to
>     carefully select the columns that fall into this category.

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.

> - columns returned in such result sets would not be bound by the
>     specification, but could be extended to include other driver/DB
>     specific infos, as long as mandatory infos are here in the first
>     columns.

Sure -- this is a complex way of saying that some attributes will be
mandatory, but many extensions are possible and should be naturally
accommodated.  Again, a good reason to not pass back an ordinal description
object.

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.

-Kevin

-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs at theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com