From greg_stein@eshop.com Thu Feb 1 00:11:27 1996 From: greg_stein@eshop.com (Greg Stein) Date: Wed, 31 Jan 1996 16:11:27 -0800 Subject: [PYTHON DB-SIG] various responses... Message-ID: 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 ================= From greg_stein@eshop.com Thu Feb 1 00:17:46 1996 From: greg_stein@eshop.com (Greg Stein) Date: Wed, 31 Jan 1996 16:17:46 -0800 Subject: [PYTHON DB-SIG] just wondering... Message-ID: Just wanted to note how hilarious it will be in two years to see this in a README: steelman.py : generic database interface :-) ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From peterw@stc.com Thu Feb 1 00:39:54 1996 From: peterw@stc.com (Peter Wolk) Date: Wed, 31 Jan 1996 16:39:54 -0800 Subject: [PYTHON DB-SIG] Python DB Sig: ILU API Message-ID: <199602010039.QAA24617@maya.kamro.com> At 07:00 AM 1/31/96, Paul Everitt wrote: >> >In a further effort to separate interface from implementation, Brian Lloyd and >Chris Heaps here are writing an ILU interface for the Strawman API. Brian is >working on an ILU module that will connect to a Microsoft Access database, and >publish it as the Strawman ISL object. Chris is working on connecting it to >miniSQL...not directly (i.e. a C mapping), but via the Python module for miniSQL. > >I certainly don't expect to get everyone to use ILU. However, having an ISL is >a very good way to define a spec. > ===================================================== BROADCAST QUESTIONS? We will be using Python, ILU, Informix etc. Does this define a subset of DB-Sig that needs to develop any unique tools? I am also looking for controls for this environment from PowerBuilder. Anyone else out there in THAT subset? Can someone give me a reference to miniSQL? What is it? Where is it? etc. Thanks. 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 ================= From greg_stein@eshop.com Thu Feb 1 03:06:28 1996 From: greg_stein@eshop.com (Greg Stein) Date: Wed, 31 Jan 1996 19:06:28 -0800 Subject: [PYTHON DB-SIG] Python DB Sig: ILU API Message-ID: At 4:39 PM 1/31/96, Peter Wolk wrote: >We will be using Python, ILU, Informix etc. Does this define a subset of >DB-Sig that needs to develop any unique tools? We're using the same core functionalities here. :-) I believe that ISL specifications (and ILU integration) of this API is fully within the realm of this SIG. This SIG is about database access. If that happens to be talking to a FoxPro database running Win95 from a Macintosh via a Unix intermediary... fine :-) >I am also looking for controls for this environment from PowerBuilder. >Anyone else out there in THAT subset? Nope >Can someone give me a reference to miniSQL? What is it? Where is it? etc. http://bond.edu.au/People/bambi/mSQL/ It is a freeware client/server database. It implements a subset of ANSI SQL. Paul & Co. have used it extensively and seem to be quite happy with it. I have yet to try it :-(. Paul - are you guys going to rewrite PyMSQL in terms of the new API, or just do a compatibility layer? I wasn't very clear on what you said you guys were up to with respect to mSQL. Further, if it is a compatibility layer, then it may be interesting to look at PyGRES (Postgres interface). I saw somewhere that the mSQL/Postgres python modules have similar interfaces. Could be that we can swipe two databased with a single compat module. 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 ================= From mpt95aes@pt.hk-r.se Sat Feb 10 12:01:51 1996 From: mpt95aes@pt.hk-r.se (Andrew Eskilsson) Date: Sat, 10 Feb 1996 13:01:51 +0100 Subject: [PYTHON DB-SIG] Module for Ingres databases. Message-ID: <199602101201.NAA22248@ariel.pt.hk-r.se> I have created a c++ 'framework' (woah nice buzzword :-) for communicating with an Ingres database. I am now thinking of making it accessible from python, and would need some feedback. What I have done is to read the code generated by esqlc (embedded sql for c) and determine what calls were made to the library, I then embedded these commands in c++ and off I went. Is this something you might need, and would you preferr some special way for this to be used in python? Feedback is welcome! /andy -- Don't walk in front of me, I might be unable to follow you. Don't walk after me, I might be unable to lead you. Just walk by my side and be my friend. ================= DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org ================= From greg_stein@eshop.com Wed Feb 14 01:41:20 1996 From: greg_stein@eshop.com (Greg Stein) Date: Tue, 13 Feb 1996 17:41:20 -0800 Subject: [PYTHON DB-SIG] Module for Ingres databases. Message-ID: At 1:01 PM 2/10/96, Andrew Eskilsson wrote: >I have created a c++ 'framework' (woah nice buzzword :-) for >communicating with an Ingres database. I am now thinking of making it >accessible from python, and would need some feedback. > >What I have done is to read the code generated by esqlc (embedded sql >for c) and determine what calls were made to the library, I then >embedded these commands in c++ and off I went. > >Is this something you might need, and would you preferr some special >way for this to be used in python? > >Feedback is welcome! Have you seen the recent generic interface proposal for database access? The APIs in that interface will be used for Oracle, Informix, mSQL, and Postgres modules, at a minimum. This suggested interface was posted to the db-sig mailing list several weeks ago; you can find it in the message archive or I can send it to you if needed. I would recommend that you see if Ingres has a call-level interface rather than ESQL/C. It is usually much easier to deal with and will be more straightforward. For Oracle, we are using OCI and for Informix, we are using CLI. I'm not sure whether mSQL and Postgres have names for their interfaces :-). 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 ================= From greg_stein@eshop.com Wed Feb 14 01:50:24 1996 From: greg_stein@eshop.com (Greg Stein) Date: Tue, 13 Feb 1996 17:50:24 -0800 Subject: [PYTHON DB-SIG] status... Message-ID: Hello all! Well, I had said a couple weeks ago that we would have a couple modules done soon... heh. As with all software projects, other priorities got in our way :-) Currently, we have a partial implementation of the Oracle module using the new API. On Thursday or possibly Friday we will start the Informix version. Considering the due date is next Tuesday, I suspect it will be done by then :-). 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 ================= From greg_stein@eshop.com Thu Feb 29 21:42:57 1996 From: greg_stein@eshop.com (Greg Stein) Date: Thu, 29 Feb 1996 13:42:57 -0800 Subject: [PYTHON DB-SIG] Update... Message-ID: We have a working Informix module and an Oracle module using the new API. Some aspects and optimizations aren't fully coded up, but the modules have met our needs so far. We still have some work on specifying how input binding will work, though, when dealing with TEXT/BYTE columns in Informix or with LONG (RAW) columns in Oracle. Also, we had to use ESQL at this point for the Informix module rather than CLI. Our CLI installation was busted :-( At some point, we hope to update to a CLI version. We have made one change to the API: exec() is not a valid method name because of the keyword conflict :-). We've renamed it execute(). I also have an addendum to the spec that clarifies its return value: [ from our implementor, Michael Lorton... ] > Previously the exact meaning of the return value of the execute() > function was undefined. I am hereby defining it as follows: > > If the statement is DDL (eg, CREATE TABLE), 1 is returned. > > If the statement is DML (eg, UPDATE or INSERT), the number of rows > affected is returned. > > If the statement is DQL (ie SElECT), None is returned -- indicating > that the statement is not really complete until you do the fetch(). I'll send mail again when more interesting stuff comes up... 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 =================