[Fwd: [PYTHON DB-SIG] Jim's DBAPI proposelet]

[Jim Fulton]

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
sets, 
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
appropriate.

Date should be more clearly defined to mean date-time.

Also, how are date-time data reflected in Python.  This needs to be
spelled out
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
disconnect and
sql syntax errors.

We need to define general classes of errors and map database interfaces
to them.

Some cases I care about include:

  - How does my application, which maintains long-lived database
connections,
    decide that an error has been raised because the database connection
has been
    lost?  How does it decide whether to attempt to reconnect, or to die
gracefully?

  - How does my program detect that a statement entered by a user is
bad?

Also, how can applications obtain error messages?  Are these returned as 
exception values?

Jim

-- 
Jim Fulton         Digital Creations
jim@digicool.com   540.371.6909
## Python is my favorite language ##
##     http://www.python.org/     ##

=================
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
=================