[Fwd: [PYTHON DB-SIG] Jim's DBAPI proposelet]
Mon, 28 Oct 1996 11:36:23 -0500
Michael Lorton wrote:
> >Hi. I sent the attached proposelet a few days ago. Given recent
> >discussions, I really thought It would generate some feedback, but
> >I haven't heard a peep. This makes me wonder whether people actually
> >got the message. If a few of you would just acknowledge this
> >note with private mail, I'll know that the communication lines are
> >still working. :-)
> I didn't see the first copy but maybe that was just me. Points:
> + I don't see how you intend to store prepare statement
In prepared-statement objects that are created by invoking a 'prepare'
statement on a database (connection) object.
> + I don't understand how you distinguish "result set" from cursor (I
> mean, I don't see both concepts separately embodied in code)
That's the point. Cursors are used in the implementation of result
but are not visible in the interface, because they are not interesting.
A result table is really a wrapper around a cursor. When a result set
is accessed sequentially, the underlying cursor is used to fetch data.
If it is desired to get multiple (or all) rows at once, for speed, then
a slicing operator may be used.
The point is that users of the data don't care about cursors. What they
really want is a collection of data.
> + I think the datatypes (String, Number, Raw, and Date) are good and we
> should keep 'em.
Note that these are type 'codes'. Yes, I agree that they are
Date should be more clearly defined to mean date-time.
Also, how are date-time data reflected in Python. This needs to be
too, preferably with a date-time data-type implementation.
> + I think the exception model (OpError, ProgError, IntegrityError,
> DataError) is good and we should keep it too.
What exception model? Where is this defined? Where is it implemented?
The oracle module doesn't use these?
We need to define how to detect statement (e.g. sql) errors, like syntax
errors and name errors.
> To defend the last to points:
> RDMSs' myriad fine distinctions among types (what is a tinyint vs. a
> byte vs. a boolean?) is almost useless (IMHO); I cannot see why exposing
> it to the user helps any.
> While the programmer needs access to very specific error messages, the
> program cannot be expected to understand the difference between (say)
> Database Disconnect and Database Shutdown. High-level catagory are much
> more helpful.
Right, but the programmer does need to distinguish between Database
sql syntax errors.
We need to define general classes of errors and map database interfaces
Some cases I care about include:
- How does my application, which maintains long-lived database
decide that an error has been raised because the database connection
lost? How does it decide whether to attempt to reconnect, or to die
- How does my program detect that a statement entered by a user is
Also, how can applications obtain error messages? Are these returned as
Jim Fulton Digital Creations
## Python is my favorite language ##
## http://www.python.org/ ##
DB-SIG - SIG on Tabular Databases in Python
send messages to: email@example.com
administrivia to: firstname.lastname@example.org