[PYTHON DB-SIG]

[Peter Wolk]

=================
Here is Greg's response
=================

Peter -

Thanks for mailing... I'll try to answer you below:

>Looking for guidance here.  Am doing a project here using Python to build a
>process server interfacing with a (PowerBuilder based) RdB (Informix)
>system.  So your postings were VERY timely.  (I learned much about Python
>from TupleDescriptor/DatabaseTuple, thank you.)

Great! And you're welcome :-)

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.

>However, I won't be able to wait until an "official" API is out.  Yet I
>don't want to modify "provided" code arbitrarily, which would mean that as
>the "latest and greatest" gets released, I would have to back implement all
>my customizations.  I know the point of the SIG is to create a standard.
>Any advice on handling the interim until Ironman?  Steelman? is released.

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

If you have requests that seem to fall within the scope of those two
classes, then I'd be glad to add them in and repost.

>Brief example: your code comment that "the term database tuple is rather
>specific; in actuality the tuple may have come from non-database sources
>..." is right on.  I am using the tuples all over the place.  Considering

Cool. We're using them in our database interface, but they haven't seen a
lot of movement out of that area just yet. After using them for a bit, I
think I realized the same thing you do: they are quite useful :-).

>also Peter Coad's separation of the domains would lead to NOT having
>__set*__ actually do a database update (as implied in your code). Set a
>flag, maybe?  Anyway, I am moving toward such a separation.

I think it would be prudent to say that somebody would have to derive from
DatabaseTuple to override how __set*__ is handled.

>Also, there is a performance consideration.  I found that a scan of 2000
>tuples, extracting 1500 and adding two columns took 23 seconds using
>tuple.attr references and 0.5 seconds by using tuple._data_[index]

ack. I could imagine. Looking at the code, there is a method invocation, a
list search, and a couple dictionary lookups :-).

You should be able to do tuple[index] almost as fast as tuple._data_[index].

This timing data is great, though. We haven't had an opportunity to do this
kind of work yet.

>references.  So I will be implementing "containers" that will hide the
>internals, but will be able to (totals, extractions, etc.) fairly
>efficiently.  Is this kind of thing on the agenda for the group as well?

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. It might be a reasonable thing to pull data from the database and
place that into a matrix object. With that, you could then do column-wise
slices and summations and other weird stuff (I'm not familiar with the
matrix stuff, though, so I don't know how well this applies).

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.

Thanx for writing. The list is too silent for my tastes, so its always good
to hear from somebody that is motivated in this area :-). I didn't copy my
reply to the list (w/o permission), but I'd ask you to feel free to post
this message to the list. Other people may be interested in your findings
and may have comments themselves (and comments on my comments :-).

Regards,




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