Peter Wolk peterw@stc.com
Tue, 30 Jan 1996 17:38:04 -0800

This is a mail to Greg from me.  His response is coming next.


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

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.

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

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

Thanks again for your efforts.


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