[PYTHON DB-SIG] various responses...

[Greg Stein]

At 7:00 PM 1/30/96, Peter Wolk wrote:
>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?

Mailed in a separate note. Thanks for reminding me.

>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?

Our engineer (Michael Lorton) was going to start on an Oracle module today,
but became sick and is going to the doctor right about now. Presuming he
will continue to walk among the living tomorrow (his own words :-), he will
begin work on an Oracle module tomorrow. This module will effectively
replace the "oramodule" from Thomas Culliton (in terms of functionality
only... the new API is not a drop-in replacement :-). Even better, the
Copperman API is much more capable of high performance database operations
(array fetch/insert, avoiding reparsing and rebinding, etc) than the old
oramodule.

Once the Oracle module is done, we (Michael and I) can do some private
distributions to people who will begin testing it right away (of course,
we'll be testing in house, too). At this point, we think we can probably
have a first version of the Oracle module by Monday. We'll also begin the
Informix module at that point and handle distribution the same way. We
don't have any experience with Informix, so it will probably take a bit
longer to develop 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

Will do.

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

The database API is unrelated to the DatabaseTuple and TupleDescriptor
classes.  Note that you can create a TupleDescriptor with something like:

desc = TupleDescriptor(map(lambda x: (string.lower(x[0]),)+x[1:],
                           cursor.description))

Then, you can push the results into DatabaseTuples with something like:

result = cursor.fetchall()
for i in range(len(result)):
  result[i] = DatabaseTuple(desc, result[i])

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

Just pointing it out. As with anything in Python, you can use anything you
want :-)

>[use a matrix object for results?]
>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.

This is an interesting thought. Essentially, a database module could
theoretically return the results in any user-specified sequence type/class.
I'm not sure what the performance implications would be, but obviously if
somebody wanted to specify their own class, then they should realize that
they won't necessarily achieve optimal performance.

My preference would be to keep the API simple and rely on a higher layer to
map the list object into another structure.

>(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)?)

done :-)  Additional notes have been added to the comments regarding the
interaction/usage of the two mechanisms.

>  If the Matrix definition does the job, then that is
>what fetchall/fetchmany should return.

As was pointed out at the conference, there are a few problems with two
modules interacting.

Also, I talked with Jim Fulton a bit about this scheme and he didn't think
that the Matrix object would be the best thing as a default object for
handling return values. Maybe we can convince him to write an email
discussing the pros/cons of using the Matrix object for database return
values.

>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

We are trying to reach the same goal.

>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.

I fully concur. While the two layers (Copperman/ODBC) semantically have a
bit of silliness (two database independent layers on top of each other), I
don't believe there is any real problem with it. I think it could be
characterized as "the Copperman API represents a Python-style API which
will be most comfortable for Python programmers, while ODBC is based around
different design decisions and criteria (Windows and C) that does not map
into Python as well".  (of course, that's a stab in the dark as I don't
know much about ODBC, but my basic meaning may be valid)

Cheers...

Greg Stein, eShop Inc.
greg_stein@eshop.com



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

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