Dear folks,
I have lots more questions about ways that the API could and possibly
should be enriched.
A. Stored Procedures:
1. The API provides a method for calling a stored procedure. Has there
been any discussion about how a user/application might discover the
names of such store procedures?
2. Has there been any discussion of how a user/application might create
a stored procedure?
* My implementation has made some attempt to address this. All of our
queries are "named" and "stored" but they are either stored with the
session (connection) or with the user account (as provided in
connect()).
Everything stored with the session vanishes when the connection closes
and everything stored with user account is visible by all connections
using that account. Thus I made visible objects of the class Server
(via
an attribute of connection objects), keep all the account info there and
provided some methods on server objects to create persistent named
queries and to control access to them by other accounts. I have no
method to destroy a persistent query yet.
B. Metadata
Not all DBMSs provide SQL access to the system tables. In fact, the
DBMS I work with most is one that doesn't.
1. Has there been a discussion yet about how a user/application might do
discovery of the table names?
2. and the column names with a table?
3. and the types of the columns?
* My implementation has done naught to address this limitation.
C. Non-SQL Queries
1. Has there been any discussion of how a user/application should present
queries that are in some other query language?
2. Has there been any discussion of the representation of query language
names?
* My implementation had to address this because our DBMS has its own
preferred query language and management requires that I provide access
to it (which I accept as perfectly reasonable). To avoid confusion
that might
arise when trying to recognize the difference between it and SQL, I
simply
added extension methods like Cursor.exec_alt(prog, parm, keys) where
prog is just the (non-SQL) program in a string, parm is just
parameters for
the query (just like for .execute()) and keys is a list of keys to
use when
parm is a dictionary (to linearize the parameters for handing off to
the DBMS).
But this does not address how a third party application might
discover that
an alternative language is available nor how it would know how to pass
such a query from a sophisticated user to this alternative method.
I doubt this is a complete list, but my mind has gotten empty while
writing
this so I will send it as is.
Thank you all,
Art Protin
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
