[PYTHON DB-SIG] Response to Greg Stein, and Mark Hammond's response to PeterBraam

[Peter Wolk]

At 05:22 PM 1/30/96 -0800, Greg Stein wrote:
>>
>Zero changes have been suggested to it, so I have to assume that it is darn
>close to final (Ironman :-). I want to find new names (and commentary) for
>the classes considering they have wider application (as you noted below)
>and post them to the main list and dump them onto the FTP site (guess I'll
>have to edit that file's header :-).
>

Well, there was the discussion about execagain. And was the cursor area updated?
In any case, is there a current listing of the Copperman(?) API that I could
use as a reference point?

> btw, I believe we'll begin work on the Informix module next week (our
> arrival of Informix has been delayed :-( ). We will begin moving the Oracle
> module to the new API tomorrow, though.

If your Informix module is together at all, I would be glad to try to get it
going here.  If not, can I get at the Oracle API, and start on that?

What would be helpful would be an example listing covering SELECT, INSERT,
UPDATE, and DELETE (and so on) with and without cursors.  Until I see that
kind of thing (or get it working myself) I find it hard to comment.  (I get
the feeling everybody else out there is a bloody genius!  It's ntimidating!)

For example, is the TupleDescriptor set by the API?  When?  How often?

> ... You should be able to do tuple[index] almost as fast as
tuple._data_[index].
Yes.  It's a bit slower but OK.

> [In regards to containers:] Not specifically, although there is nothing
stopping us. Mainly, I
> think so far the list has been to create a way to deal effectively with
database
> access from Python, rather than what to do with the stuff once you get it
>:-).
> In your particular case, you may want to look at what the matrix SIG is
doing. ....
>In any case, I'd ask you to feel free to write to the DB list asking about
>the problem. Specifically, how can data be pulled from a database into a
>form that can be efficiently manipulated in the ways you mention? Also, if
>you find the matrix object does/does not turn out to be handy, I think it
>would be great if you could send your results to the list.
>
Will look into this, but I don't want to mix protocols as it were.  The
TupleDescriptor IS the column labels, and your definition of the fetchall
returns exactly what I'm using - a list of tuples.  So what I want is a
defined "Container" class returning this tuple list. Now, I would want to
sub-class this object to add my own handling, and this would require me to
specify the container that fetchall uses.
(cursr.fetchall(Container=myContainer)  This applies to fetchmany as well.
(By the way, should it be cursr.fetchmany (size = 10) along with
cursr.arraysize(10)?)  If the Matrix definition does the job, then that is
what fetchall/fetchmany should return.

COMMENT REF MARK HAMMOND'S RESPONSE TO PETER BRAAM

Peter made an argument for a 3-level DB model, separating the functionality
from the connectivity. Mark's response basically said "Why bother?  A site
only uses one database anyway."

My situation is that we are preparing a component of a product that is sold
to many clients who potentially can have ANY commercial database.  For this
reason, an API connecting to ODBC allows us to move quickly(!) from one site
to another WITH IDENTICAL CODE. So this is valuable for us.  I also
understand that this will simplify running on several platforms connecting
to the same database, as well.  So yes, Mark, it is wrapping one independent
wrapper around another, but if the design reflects Peter's architecture of a
single front-end talking to a set of (DB specific) backends, then ONE of the
backends should be ODBC along with ORACLE, INFORMIX, etc.  And I would
support that architectural approach.

Peter-

------------------------------------------------------------------------------
Peter M. Wolk
Director, Managed Care Research and Development      peterw@stc.com
SOFTWARE TECHNOLOGIES CORP                           818-445-9000 x506
P.O. Box 661090                                      818-445-5510 (fax)
Arcadia, CA 91066                                    http://www.stc.com
------------------------------------------------------------------------------


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

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