From Olivier BERGER" Hi python fans. I've searched a bit the archives or general Python DB documentation, but couldn't find any clue on this, so I'm asking you, and pardon me if this is a really trivial question about Python DB usage... I'd like to have a Python framework with classes encapsulating the physical tables and columns of my Oracle database. For instance, I would have a class called OracleRow which would allow me to map automatically the results of DCOracle fetch results to an instance of a subclass of OracleRow. This would, for instance, give the following : class MyTable(OracleTable) : def __init__(self) : OracleTable("mytable") ... ... so that I get a MyTableRow class corresponding to rows in the MYTABLE oracle table, and then I would be able to do something like cursor.execute("select * from mytable") for r in cursor.fetchall : instance = MyTableRow(r) do_something(instance) and if MYTABLE contained the ID, NAME, ADDRESS columns, then I would be able to do a : def do_something(mytablerow) : print mytablerow.id, mytablerow.name, mytablerow.address As you see this kind of framework would allow me to use the MyTableRow containing attributes allready mapped to the corresponding columns of the Oracle table. This would have been made by analysing the oracle meta-model internal tables in order to know the proper mapping. Such a framework allows automatical encapsulation of low-level tables into obect instances, thus facilitating the algorithms writing. Have you experienced this kind of framework, and can you direct me to the corresponding source code (if available) so that I won't code it myself (with all the resulting errors... ;) Thanx in advance. Olivier Berger. From tbryan@server.python.net Thu Dec 2 13:18:51 1999 From: tbryan@server.python.net (Tom Bryan) Date: Thu, 2 Dec 1999 08:18:51 -0500 (EST) Subject: [DB-SIG] Oracle tables encapsulation In-Reply-To: <006b01bf3cb1$2c71d9c0$640105c0@mcotlc.bk.fr> Message-ID: On Thu, 2 Dec 1999, Olivier BERGER wrote: > I'd like to have a Python framework with classes encapsulating the > physical tables and columns of my Oracle database. For instance, I > would have a class called OracleRow which would allow me to map > automatically the results of DCOracle fetch results to an instance of > a subclass of OracleRow. > > This would, for instance, give the following : > > class MyTable(OracleTable) : > def __init__(self) : > OracleTable("mytable") > ... > > ... so that I get a MyTableRow class corresponding to rows in the MYTABLE > oracle table, and then I would be able to do something like > > cursor.execute("select * from mytable") > for r in cursor.fetchall : > instance = MyTableRow(r) > do_something(instance) > > and if MYTABLE contained the ID, NAME, ADDRESS columns, then I would be able > to do a : > > def do_something(mytablerow) : > print mytablerow.id, mytablerow.name, mytablerow.address I haven't seen anything like this on the list, but it wouldn't be difficult to do with most databases. OracleTable simply needs to query the "data dictionary" for the appropriate information, assuming that the user has the permissions to query the appropriate table of the data dictionary. Something like this might work. I'm sure that it could be made much better with some thought. Note that I don't have my Oracle reference or an Oracle database here so that the column/table names probably need to be changed. Untested code follows: class OracleTable: def __init__(self,tableName,dbConnection): """tableName is the name of a table in the database for which there is an open connection referenced by dbConnection""" cur = dbConnection.cursor() # not sure about COLUMN_NAME, USER_COLUMNS, or TABLE_NAME # check your Oracle reference materials cur.execute( "select COLUMN_NAME from USER_COLUMNS where TABLE_NAME='%s'" % tableName) columnNames = cur.fetchall() for el in columnNames: setattr(self,el,None) cur.close() class MyTable(OracleTable): def __init__(self,dbConnection,**kw): OracleTable.__init__(self,'mytable',dbConnection) for el in kw.keys(): """how do we make sure we assign to the attributes in the correct order?""" setattr(self,el,kw[el]) The problem, of course, is that with the above code, you'd have to do something like row = MyTable(connection,id=10,name='db-sig',address='db-sig@python.org') It's more generally useful, but it can't be used like you wanted to use it above. I'm not sure how to ensure that the values of a "select *" would be assigned to the correct attributes without playing with it a lot more. I don't remember how to obtain the order of the columns in a table from the data dictionary. > Such a framework allows automatical encapsulation of low-level tables into > obect instances, thus facilitating the algorithms writing. Nice idea. :) just-enough-to-get-you-started-ly yours ---Tom From jim@digicool.com Thu Dec 2 14:58:40 1999 From: jim@digicool.com (Jim Fulton) Date: Thu, 02 Dec 1999 14:58:40 +0000 Subject: [DB-SIG] Oracle tables encapsulation References: <006b01bf3cb1$2c71d9c0$640105c0@mcotlc.bk.fr> Message-ID: <38468920.12033E25@digicool.com> Olivier BERGER wrote: > > Hi python fans. > > I've searched a bit the archives or general Python DB documentation, but > couldn't find any clue on this, so I'm asking you, and pardon me if this is > a really trivial question about Python DB usage... > > I'd like to have a Python framework with classes encapsulating the physical > tables and columns of my Oracle database. > For instance, I would have a class called OracleRow which would allow me to > map automatically the results of DCOracle fetch results to an instance of a > subclass of OracleRow. > > This would, for instance, give the following : > > class MyTable(OracleTable) : > def __init__(self) : > OracleTable("mytable") > ... > > ... so that I get a MyTableRow class corresponding to rows in the MYTABLE > oracle table, and then I would be able to do something like > > cursor.execute("select * from mytable") > for r in cursor.fetchall : > instance = MyTableRow(r) > do_something(instance) > > and if MYTABLE contained the ID, NAME, ADDRESS columns, then I would be able > to do a : > > def do_something(mytablerow) : > print mytablerow.id, mytablerow.name, mytablerow.address > > As you see this kind of framework would allow me to use the MyTableRow > containing attributes allready mapped to the corresponding columns of the > Oracle table. This would have been made by analysing the oracle meta-model > internal tables in order to know the proper mapping. > > Such a framework allows automatical encapsulation of low-level tables into > obect instances, thus facilitating the algorithms writing. > > Have you experienced this kind of framework, and can you direct me to the > corresponding source code (if available) so that I won't code it myself > (with all the resulting errors... ;) You should look at the SQL Methods facility in Zope (www.zope.org). It does exactly this. I suggest that you download Zope and take a look at the file lib/python/Shared/DC/ZRDB/Results.py. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From sjturner@ix.netcom.com Thu Dec 2 15:12:36 1999 From: sjturner@ix.netcom.com (Stephen J. Turner) Date: Thu, 02 Dec 1999 10:12:36 -0500 Subject: [DB-SIG] informixdb 1.3 Message-ID: <38468C64.7510525C@ix.netcom.com> Announcing ---------- Release 1.3 of informixdb, a DB-API 1.0 compliant package for Informix: http://starship.python.net/crew/sturner/informixdb.html This release fixes the 'fetch{one|many|all}' method output types and/or values for several SQL types: - FLOAT, SMALLFLOAT, DECIMAL and (for locales with trailing currency symbols) MONEY mapped to Long instead of Float. - MONEY (for locales with leading currency symbols) mapped to a NULL pointer, possibly crashing the interpreter. - DATE mapped to dbi.dbiDate (as it should), but always with a value of -1. - INT, SMALLINT and SERIAL mapped to Long instead of Int.

informixdb 1.3 - An Informix implementation of the Python Database API. (30-Nov-99) From ORENGM@powell.fabrik.com Thu Dec 2 18:10:00 1999 From: ORENGM@powell.fabrik.com (Michel Orengo) Date: Thu, 02 Dec 1999 10:10:00 -0800 Subject: [DB-SIG] Oracle tables encapsulation Message-ID: Hi Olivier, I've done something similar with sybase/MS SQL using ODBC. I was kind of proud of it when I read on the news group the anouncement from Boudewijn Rempt about a framework to give an object-oriented access to relational databases. He called its stuff "Database Object 0.2.0" What he did is far more complete than what I did, but quite similar. He uses a data-dictionnary to create objects/requests. In fact, you can create this data dictionary with requests to the catalog/system tables to get names of tables/columns and types. I think it is worth looking at his project (even if it's more complex than what you try to do) Also, on a similar subject, I found an very interesting project from INRIA called ObjectDriver (http://www.inria.fr/cermics/dbteam/ObjectDriver/). It provides an object mapping to any relational database. It's really cool, and you can query the database with OQL. If I had time, I would create a python binding to it. The bad news is that they want to go commercial and they don't know yet the pricing framework. Michel Orengo ____________________Reply Separator____________________ Subject: [DB-SIG] Oracle tables encapsulation Author: "Olivier BERGER" Date: 12/2/99 2:36 AM From: Olivier BERGER Date: Thu, Dec 2, 1999 2:36 AM Subject: [DB-SIG] Oracle tables encapsulation To: db-sig Hi python fans. I've searched a bit the archives or general Python DB documentation, but couldn't find any clue on this, so I'm asking you, and pardon me if this is a really trivial question about Python DB usage... I'd like to have a Python framework with classes encapsulating the physical tables and columns of my Oracle database. For instance, I would have a class called OracleRow which would allow me to map automatically the results of DCOracle fetch results to an instance of a subclass of OracleRow. This would, for instance, give the following : class MyTable(OracleTable) : def __init__(self) : OracleTable("mytable") ... ... so that I get a MyTableRow class corresponding to rows in the MYTABLE oracle table, and then I would be able to do something like cursor.execute("select * from mytable") for r in cursor.fetchall : instance = MyTableRow(r) do_something(instance) and if MYTABLE contained the ID, NAME, ADDRESS columns, then I would be able to do a : def do_something(mytablerow) : print mytablerow.id, mytablerow.name, mytablerow.address As you see this kind of framework would allow me to use the MyTableRow containing attributes allready mapped to the corresponding columns of the Oracle table. This would have been made by analysing the oracle meta-model internal tables in order to know the proper mapping. Such a framework allows automatical encapsulation of low-level tables into obect instances, thus facilitating the algorithms writing. Have you experienced this kind of framework, and can you direct me to the corresponding source code (if available) so that I won't code it myself (with all the resulting errors... ;) Thanx in advance. Olivier Berger. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://www.python.org/mailman/listinfo/db-sig ---------- Received: from dinsdale.cnri.reston.va.us by powell.fabrik.com with SMTP (Fabrik F07.3-000) id SINN.15067201@powell.fabrik.com ; Thu, 2 Dec 1999 02:39:47 -0800 Received: by dinsdale.python.org (Postfix, from userid 60001) id 6938F1CE96; Thu, 2 Dec 1999 05:38:59 -0500 (EST) Delivered-To: db-sig@dinsdale.python.org Received: from python.org (parrot.python.org [132.151.1.90]) by dinsdale.python.org (Postfix) with ESMTP id 2A7551CD52 for ; Thu, 2 Dec 1999 05:38:57 -0500 (EST) Received: from gw.capgemini.fr (gw.capgemini.fr [194.3.247.254]) by python.org (8.9.1a/8.9.1) with ESMTP id FAA14132 for ; Thu, 2 Dec 1999 05:38:49 -0500 (EST) Received: from prenoms.capgemini.fr (capmail.capgemini.fr [194.2.91.200]) by gw.capgemini.fr (8.9.1/8.9.1) with ESMTP id LAA08345 for ; Thu, 2 Dec 1999 11:38:46 +0100 (MET) Received: from OBerger.mcotlc.bk.fr (localhost [127.0.0.1]) by prenoms.capgemini.fr (8.9.3/8.9.3) with SMTP id LAA03568 for ; Thu, 2 Dec 1999 11:38:47 +0100 (MET) Message-ID: <006b01bf3cb1$2c71d9c0$640105c0@mcotlc.bk.fr> Reply-To: "Olivier BERGER" From: "Olivier BERGER" To: Date: Thu, 2 Dec 1999 11:36:00 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [DB-SIG] Oracle tables encapsulation Sender: db-sig-admin@python.org Errors-To: db-sig-admin@python.org X-BeenThere: db-sig@python.org X-Mailman-Version: 1.2 (experimental) Precedence: bulk List-Id: SIG on Python Tabular Databases ---------- From dillera@isc.upenn.edu Thu Dec 2 20:50:42 1999 From: dillera@isc.upenn.edu (Andrew Diller) Date: Thu, 2 Dec 1999 15:50:42 -0500 (EST) Subject: [DB-SIG] Mysql insert_id() questions Message-ID: Hello: I'm trying to grab the auto_increment value of my most recent insert. The MySQL manuals and the MySQLdb both mention the mysql_insert.id() which does exactly this. I'm getting an error though, in my cgi code: ------------------ db = MySQLdb.Connection(db='example', user='test', passwd='dontlook'); cursor = db.cursor() .... sometime later: cursor.execute("INSERT into database some stuff") recordKey = db.insert_id() I get an attribute error on the assignment: File "/usr/local/apache/htdocs/usginfo/incident.py", line 142, in ProcessForm recordKey = db.insert_id() AttributeError: insert_id Does anyone have a sucessful code snippet to retreive this value from MySQL? thanks, andy diller From zen@cs.rmit.edu.au Fri Dec 3 00:14:15 1999 From: zen@cs.rmit.edu.au (Stuart 'Zen' Bishop) Date: Fri, 3 Dec 1999 11:14:15 +1100 (EST) Subject: [DB-SIG] Oracle tables encapsulation In-Reply-To: <006b01bf3cb1$2c71d9c0$640105c0@mcotlc.bk.fr> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1538048050-944180055=:2058 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Dec 1999, Olivier BERGER wrote: > Have you experienced this kind of framework, and can you direct me to the > corresponding source code (if available) so that I won't code it myself > (with all the resulting errors... ;) I've attached some code I've been playing with. You can create a 'Table' object, passing a list of columns that you want to use to restrict your search. The table is then encapsulated in a (possibly nested) dictionary interface allowing you to retrieve individual rows or tuples of rows through generating the relevant SQL on the fly (and storing the cursors for reuse). It allows you to plug in your own UserDict subclass to return for individual rows. Its currently Oracle specific, since there is no generic method of binding parameters that I know of making it rather difficult to write cross platform database stuff using Python at the moment. con = Connect(blah) t = zdb.Table(con,'%s.users' % tsgdb.schema,'uname') print "USERS table has %d tuples." % len(t) print t['zen'].items() for k in ('zen','fred','31337'): if t.has_key(k): print "USERS has tuple with key '%s'" % k else: print "USERS has NO tuple with key '%s'" % k print t.get('zen') t = zdb.table.Table(con,'%s.insubject' \ % tsgdb.schema,('uname','subject','course','year','semstart')) print t['adick'].keys() print t['adick']['CS577'].items() print t['adick']['CS577'].keys() print t['adick']['CS577'].values() t = zdb.table.Table(con,'ALL_USERS','username') print t.keys() print t['ACC'] -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen ---559023410-1538048050-944180055=:2058 Content-Type: APPLICATION/octet-stream; name="zdb.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="zdb.tar.gz" H4sICN4KRzgCA3pkYi50YXIA7DzbchtHdj0AbwBJkbIsUZK9cluWloAFgwB4 W3FF27Ika7WSqZikrbIYLTPEDIiRQAw4MxBJLZXZtZ2Uc6vNbq6bvOUhL6k8 5S1VqVR+IH+wz0kllR9IVapyzunpmR5cRNK2KLtMUAIGfTl9rt2n+5zGE2Nt gj3nV6EwVZidLsBnoVAqTdNncXqGPoMXK8wWirOTM7PF6VkoLxYnJ6fYNDuE V9P1dAeGfGLWn9nOc9f3IBKIm5kMiCqxb8nrCch/s2k6O/nGznOTf7FQmJma 6ib/ydkZkPnM7GxpujQNHyj/yWIB2h/J/7m/xsfH0xduGXNcKkHuMS/mS7x4 +fLlicLlidIkL5XmJmfnposcWMRvbDf4hfTy0k1u6J6+prsmt+qe6VT0splG YGlro2E7Hnc9x6qvy29e1TF1I11x7A3u7TRMlwcVb6bTq+Wm49qOy+f5T5+m 0+Wa7rr8Q0Rnjqc5vADsVYEfwNE9XtbrfM3k5rZZbnqmwTeaNc9q1EzuWRsA uWI7fEPftjaaG7wBmNnOhl4vm3mCBa9lwoW7egVwr/Adu+nwxs719/g1u143 y55l17m99hCe5EhuVXdgnDXT2zKBB4IYNycBwngAx6uaKgTLrY97XXrm+S3J My6BGM1GzSrrHhCAkAghwZiIwXyrajom1xvUdK0W0SQ/r9VsF9jeisyaCVww kVRe1R+bvGLVLbcKiG1ZXhUaWwHDAWsJqeGYnrcDYmw2LCNPkiU0zQpfXYXu 3upqxjVrlVzZrufczVp2Lp2CVteAQA9Q5HVzK4ApeJlPp1PQFDhiN2vIEWjz WK9ZhiC1mC+08x+6AOQOXZY+vCMUgsbEZoBJfhUbz3N4lwU44DyH93QKJFS3 PS6VLV/V3dVH5k4mbIgEIIWyxUpY8yDQTEl/oHiC/Ibu6Bvu/IJdNwMW3BDV JIN16zGInVDN8TWrbkjhUDcT5AritqkEaSrbhklYNMAGQDxWnaoABzCnZtmz nXRQjYOGhgBCNB1gjmvCSKDqqJHqt0r4jKpHqkpgaiAqJ0dDCPPasmo1GNQ1 wTJDq3LsLZdnQikZtkmqDZyw6gLOFlol9a2CbgLBpFYhAOATCNNFrNxmuZql PvS2aLrQyIWmroeUgM45lvkYLWaH0HKBSYHVCNu3XLcJ1YEIhPDLIB/kfzrl wZNonV83vVXLMOteJptuk74i21ARPKkACC6sz4semWxX5VjxUD/K6ZRZc00F ROemgMsbDZgZPX4e2oGqzvGL7nl+kYcaHDUQUg4beE5GlAQEBUowL4iXI+dV 7SSAWUQNJyiYdyUE7HXHcr1lKOveMwfGXwv7ZOMkdmgeoUdlhumWHatBBg0c in1/g18FSeJ07eFEFmpVuarX12FWTOELWsmZs6zXamQqwaioIGEjm/Q/mFwj O62YXrkKrCEMUbpdxdKmMg/SKdDFpgMD50Mw2RbQsKyI+SPnWk/MQAm/4jgC JoBrHQzo/zroQDAAOub/yfkcVv/y8/P/uvv/M4Wi8P8mC7NT09Pk/80Upo/8 v0N4/XphOH35N/85S4LX4L87B28+YwZj9+FhgPlp9khj9zXmD7JHCXY/wfxh ZmrMSrL7SeYfY2aCWT3sfg8zNLaUSSCMf4E34VYqukWeZTHyLMHJnJybmpor TSueZRoUEma28iMdZoG3+H2zPu5GrqZjNz1YdGAVS6fvOnoZF5eGWbYqVpln YHkRE0HYnFaMpguTzPhcozgeLsDkEnpZWJGbXpq8n7L0MCrWtmnk0wuZXqSj H95WVw27vLrqYgGtkvREsxY9fRiWLWNZBhnpHoe3/ESLcbnI33cGmDsAn0OJ lJZKDGnfgP0f0fLC9n/FydnJWbn/n5mdFPYP/47s/zD3f1IJ9rX/Uzd6wg+X +zzc24ltntgAyn1ezd4yHVEhXM1w/0dlH4HLed2CHVe0LRT7QLKpRXsrI1tk 58g5jtXPPWNrQnTlwMEr2zU3B77sNew3L+HmVg2z4VXnCzlYQhs784XAiRde iSU2Y/Sljq5ohjzrwJ9vOPZjWGdhKwlY19BNrzU36hwbuuQkwd6Pi+XXNLJ5 KgoQQchxD13tLCYu4WBz3J5CL7EFQ7+PEJ0LAIP3cwsotmBb9AQwIWai9x3u HBo7mSyHnUbVNqRfpuyK6LugdZ6fz1x0s+hqUoHcQwkGocdBD2Ex4IRb9pUH AivyLgPqOrmXknBw0MmplE1V51TtvoytOvYPnlbmHsQc0qiBhJMLPVHCNt5d VkmNgBr52IUg0u38Eql1R8SUcTsjFqccRLfUME3jHdEMd3xoKGY9avE2LwAy G3ojQ/aTi5hGuHckarN208R90PjSjTs3ri3zN/n7i3c/gE0Ev/ejG4s38GGe 03J4kWdi1rFSeACQ8fjEwp2ng554pphTMZJ7pHCU4OESH+dXF65L4BcNgi7h Wg9y1qViNhQG2Y/oT6tnJjhDgCJFZNTqdqhlSFnwTZJ2/dbS8q0FeBgPa99H A4AWgEhAdgyTwgMxIWTDDncdA1wG6MHvLl6/scjf+yToE3VpxyhP21wjE8Me Ky4paFxSR8jyYNfWIt9ixNB9oF+M0Fc63aNTISShXcIqFUqXPakuyvZdKMfN 176oJ+TaWEGw23St1E3X9sEa65msiX3dQ1nfAi5b2YOxy3q+7Ipr4Md6rWkq VhF+bzP5cWUyl+0OrPCiW0hJjIxg6Es8Dn4f2i5aH1B14xS0FIBYc/vQ4hZy frtVMu0kSa3pRON+NThObhtoxOIgSnlQRljPnREq5DtmPdJO8UWq5rW7Hy0s Z8KJGxyOPefpOODOeggV+9C5/aLSpozImw7TcHzhbOXv3sjuV3m+HN6oQi2I W62Ix/XqIMhLj5s8THkwBT7qonBLdQx91MBroQbo4NI+W5zroyubssNj1lVy 5cFpx/OzXMtbIVdUnRLpk8JOAPbUlmduuBnJKTusWLFAJHgsa9EUYEfuag28 0oziwYIXiY7YAvhh6JHX7LJeEyh7Nq806xSOCA/RbDUIAhucYKOBCAQt8JSW wAeoZdUejtno0AVLu/dZNz0sllsawPkxmh5xO+C1PP+vi+OPcbRQiUbI3CxO C+PjIjQAnq5wRtMpcOpNcSoCu4IqlNd1B6tx2+GaulOu8qru8jWzbG+Y4R4k tjV4e55sTnVJs/yt0PDkOTWPs12tlKoWUteukOAbhifO8pyZGlkhZGAV7hRb eslmFWwZnpWnHN1yTQ6r7A0g1wn5KhoH3ruUkBXz50PFFZsrRfeCjVL0fIkX o+pHij/QQmgn9QKWKroiZY2bunpzYw3kDDZlgDZboKOctBvMA+2EDK1mPjZr YGWbEd+lXa+owgMxbLac5BOiWVJP6Lypnn9HKuvhshxiiz1iqFIUh8MEQAhL 7HS3LHUNF44O6KHXczD8cJXR4RMYvVW1YB+rB2LSI+TpUD1gNXJojZAJBCxF siZm8YjCiDwSVUcCaT5BSaBEc0KkwrKIYCjcB9FiLT042U6L5ruZzazkgjMX ahbA8ZBARypbx26d6Bbz0ddFNsyytoeHuhjpDE5WKL4H04tjbjYtR8T9Am5n uWtDedM1vz6O2a1zRcQwW85WIvZ23VxrrquhNzsy1XBhzNgr8eOFOEYPcna4 1+k4cieeq3Hp2GzvOTuKZmP1iqx+EJtFwBLM7TJgEM5uc7H6QjrMGMABAZ/4 YDmjEoazo0HtZw9q7zGoUVHmNmWizpE8A9/hfTRWdB1AbUTgWRxooaaE2R7B 4ZteNyRsPcwXwBHxLI0OdGLHO3m+HPkfsoHIKzA3mjWRs7ABgsWkFQSDpz08 Y67nw7PJfHhISYHsNQKSJV+G5hpKoIlNlmFcGhYfnV95Ww3UhlYoMZQTFEZJ Q3BKyDSavhSXsUAuo07OYspZoVOiDHYCVw/nM/SBdPL+pa61icHtLoeKuSWi //uSgpwUhBSI0e6Xl4Y4QJUiOZg41uLikNO/lAf4e4qGVe0azE/RLAG1y0Ap eEH6Dt8ylUNcUo0KOVAggLW50LFQZZvqKNhUd6mmniVS0pRnibVlSnJaZpU9 z39bQlQvIv+vMFUM4r9QODVbpPjP1NRR/PdQ4z/f0kBt90gUHXulRQqaNDz6 ll4O4h0i5LUsGrLv5kvN/y0/pzH2yP+Yni5Oy/jvdKk0SfZfKpaO7P+Q8j/+ 9R/+S+R/JDF14XYs/6OH+X0y/6Nf5n8MsEdJVuthmp9mVWjXy/whzP6oQLcE +5yxzxj75H4fM5JsKdODQH8cJoR8HXnGUd4FoZ2AP/e3EO0hifYJ5p9EjAAX xPw8JqkgahrlrFxDzLAKqLtJVT1UBXTcZkYvVfWxxaVMH+L+M42xo/zjF5t/ XE4y8ed+gHI+yfxXmP89tptgu4ytgkqeY7saPYNIX2NeL7P68KvVwz7T2JD9 MugqR12FGlF8pa4xLcpY2oS3Q89dXshggpFLZrdZc8lSwEGjB0yopBpM/qUC fBigB5H5R9lJcrtIMEIAsp+EfCxMR5LmJyAFa/5J5uL6l+xLJoa0IW1MKydY D/wBu/8P2X2e+W8yP8c8xp4Cr99iXgLTv8DKn4I1TUim9rMz1gDbTQqWvwks LwTlVooaQ98iyixqD42v1E9Cy8l44Rls+wOUKYz5MMHsMWhzGftag9RsCAfR 6h9A8RzzhrElFHjHqDGH0h/GGnsjQYvPEtALgc3H6ndFjf8OlY6SJo0qCW0w A7KjvO5Dy+teyByX+ozbKkqcK7s4GwczWAoewzRXqvbithG3JWS0Yi0EKWiJ j4Lt1CJAIDJBfKDMDwQvc1pECiCddw3Ck7KfE8tdOLoCXdAgUO1gj8rg55l7 Fs1xIJlIaSOJV7SXtNOJl3tHwTBPaTxxKlHWaM0D88yjeV5j/nW0E1TlBDvj JWnaY2BEsPTdQN2GyRC+L8HiuJRBDIKJZw+OPZPfZeodHnckYmSLBl1mHdnn muiQ1M7ifJMUBBWRoJvM/1FngmBWuEUm2hfYs0rTwFenKSXxwzMD0d16YrbM rrK4O5kxMDcVOuOCu838O10F98HzFxwmgx9UcNDndkSQQEdNk1XXlciAVdNS daCF4THMKJG2Ayqh8zfE3CF4TvXDsjU88vpQz0jPQjtC5MNR0pbKl15p1kTy m3GOhiN0xYEyeXvEskmZvFo6kUp8S/d/1z5eeq53gPd1/zd+/7ME/4/u/x6i /Bdt23u++d/PkD/u+en8r1go0TlhsTRTPLr/exivCdohTrhOeaL82HVAC76r J2Hf3fM/sn+zATt32IjsvAD7xzsfcfufKkwf3f84jJezYXkTNp3QTwCJoA2N HQ88M3R3jmaC747936jjDt19Iet/qd3/m5wsHdn/oaz/StxvopgvTtwzDb5k Nrga9aND+ol0uP2BhqWJ5WpTNFRO7mVDeZlsr4bXj6aYb4D9S2m9mPhfqTCN v/Uj739Su+JkcfLI/z+s+N9v/mf+ByR7OgayY/G/JPN7ZfyvT8b/+sP43wDW 1XrhKcUe9YmnQTw3N/tYRVOjgf14bdxIUoywJywdwHBbEGebDGOEB7qLSkc3 8jpncI09IY7IABX4tyiPzrCu9URHDhWDMsjcBIVDo2vdAX8A8D8i4GG6+E7h Tvynsc+TxKJ1GVkELtkBoRhxdGRYsYf5TWb00XMv879gRn8QbvR/wYwBegZW /S0zUvQ8wPy/Z0aanlPM/ydmDNJzmvn/zExg9RBFLoeY/2/MGKYqwO3fmXGM no8h9SNIfbmfHWcDSNMdIAqw949jmHS3j9mDILQTFOzAmJh/UobSgJ5TSN5u gp3C70DHGNulMM0q4H6ardPR5SrgfpZ5/UHkx0tRDOYEQHqFwW5SlD5NsnoR il5VGg5Sw2NQ+j0sOodthuHba/itQn381/EZBwEK32C7PfQMFF5U4Bxj1giB GoXO348616fgeyaGg59l3iizzzLNOx6UgsAe9rBGPxS9xD5FBlxi3gnmvUz1 GBTKSRxAGHkUKoYdk9jxTAVY87QfY2DbV5l3CqUcAoa+BoXHnIvsKXQtsN1+ FD0CG2Bndkn3xxDCGIDYfKjd84vMO03c78feOOQZ5k9KPp9l/hTqy1NQhGlU lgAJQIfwAJ2YQb0Jik89BfWfpcPls8w6J0FDfZqN7Q6yMRgCg2j+5QhnwAiY YZsUVgtG6I2N8EPUxnAEkMoVOWRvMOR8tyGHYsOSrr3Ltn9JfBts49u7zGkS 364GiBDTIkTeYwAwZCeMfhpZKtg5RDH+lOxFaF3fH1qbf5e459+ULOcYiQAb QxN4OozBB5W/YEQ/JqhcgTrMdo9FvL3TxtsFKP0gxsQR5i9gJ7BfyccxhH23 E+wRwPZYnImLbPtJFyYuMucnxMQl7NmFWzD+R9H4xDAa/+O9x9/8j+Q9/xPJ rQvMv48zT4tejjJ/hUBdUECNMsmiB20sehtKf8KMEUX9pL0lBbzf6Q6PWLLG tstdWLLGnJvEkjIzRhW9auFMjxjI7D7Q5v/23KMIMcUqf8WCHwX5Rv1owAKF YPBev0UL32vwtse9cEuTK2T8PqI7GvUNL59RACS6kUvxGPVeqYtrT+sAFHIa 7YAJIYtXF93Xo9ru193cwn5atYxOEcYD36TLfB9x7hUBNvAW1MQMCpxFvwmD voy4AOAO4yO5D8GVAOKPLMFAdBRexpBVIOduoWaMlYU/i0CcVUCFHWXasRLi QiFFv1tAcBChteb66iqRAopKEr9Kv0Fg2XXK4KeqDb1BkCgHWQTT6KI+FVLG MgXDLOW3cEYVzOQtLPpFnFghXvUhqoPLzhRJV25EE6/Ui9A0uMhzVuvoUqp7 ohW8uCJCtIbXVYnG+OXVeJGA1Yb/HbMuKYfHKDchlmsTaUCrKEOJKKoRqZLC UsHIA/GkjRFfhuCItm6esTwlOMbcn6FnnEwm0mwwMaSNakPaUOKUdkI7pR1L DNHfGW00MaJdSEBdYkx7haW0N7ST0DaljWnHofwUfR7XckmsG9Neo+chbRg+ OdQe105qGap7LYFPmJH0KpSfS/AEll5M0GRW1sCb7UeP9lN0ydeZX2W+RfO1 hhlK4T+DNiKf9TEMqz9k21NBCpjVi5sQgwqdc5Se9AhXemh8BmPv5OhB9Zkr m1fYPb9GLif0HGDnYP6HFugQbuDDUpTpeAHe9nMHlkiwxMYkFVMoYZ7Btc14 DowdCEPcciUlojtageZgW7yE0TbNtCQwCFCiTweB95BGN3bWxTKQ1JLa69pJ YPyrIGTguiZSGDBHBTY5fiNKYQB2tuRkJMMEN8+Jz5bicpkWQ6wDMiKUT3dt 7WBb1oqDw3x3TxxwDLxp+6WQEFwX13edEIsE6xU5if+NWDSZ/xi1JUJEY2Og SmOav0MlSebR9gXVjrYdpx/2MrsB3soTKu6DHRCo4E8pv2UgyG/R/F2qTFOu WuAxPZVZa1QR7Gx+Fz2YIAEON0J+kPT2aYLVB+D7z7F+qT4Pj59Rz1HKyYMN 6ee4r7LIwRqDJ9zn/R4V9al4/D4WCbaSTrqnIk1vuYHsvo2r/le6aUyWkXmp o/bEDaR9kZUrmjoPty28SmaWsq4MiC7iCmLHdUzNZCHdDG5RRRZI1oqA5E24 0KCE4YmflgupiQ3Zki9mBabaQSUHiQnh7fBmkDOmnU5ymEhHYUI+Ce+jiUGY ik/AH82WZDOYi+1/wfw/YP4fBrNlkICE8+MfsWDqk4qq+X8cZSKhgv6JnBaX QLuXhHVNRbpwoBvKNAsGmVshRzquv+1iRtZsxuTRJuRYqlGSZgCvw1y4Keu6 T0B0G/uLIE8WJkRk6QgytZcmAfdvkKm/YP6fMv+X7Uz9VTtT/ww3TcjOP0de ogH/Bdu+je9gpva70OIvqdOATLP9K7Y9TtugBD47Z8l0/5omizSaJq5atC2x 2L3N60y75/8aK5WlKSOEtK+72WR/gXQGYwzr7Mh9KfFIrmNTvSUVDMvWFNNs sZq42AQA0aXLgvb/7V3raxxVFL+7m+xmtxMqtUoFC5q0zi4siZutBkK/1FD0 Q9yKi0QtJWx3E4yxu+7sLm6KMqCfBMHPUrW+qPis0mql9UHBt1Ko76p/jOdx 586989hEaoXATiDJzNznOb97z7nn3nMGK3xedHZp/MNjW2mRAz5aINx2IzdH eIg8i9w8IdwXhftSmJsvh7l50uPmK/IQM8+ayLdXRb+Ev5Gtt0HS14hlWbko TbivB3O070XmvcHMUyeQ9xvM+/cO2JV8ziBgnMJ8VYwc0yZEysdKu3RAH9mA g04U7zA/z40nRGenwb0dxD08Fkuco/Pqp5Fzp4T7pnDfCnPu7TDn3vE4926I c++J/iL+Rs4tQNL3Sbx7nLvx7nvc097wI/ugPE0OdeER9hUprD+I5u+HzF81 g14tf2n4KK/1St669twOir+WEtWaRI1Ypm4IhEiBp9S1U4JUD8BBUsfBjsQe 9lxI8Yx8FyLhjHDPivVdwv0IuQAsoCPEH5Oxe7G5W7jnxEg3JR7NkR0aLvcT nEirzaRIPEi6Drar4s+GgbYbwptnIV3yB2RNROoYgSMPqp/xBE4aZPo2WBjV UwBzv3vnhXuBuvep6h7g9jPS9Kh7nwe79wXBzu8ea8ijg5vZMtUZnI8aK4Mo wSnieZniU8nnQ91LijQv6U5i9y4K90vhfkWDNuGpH18L6BF28xtyJYHewfBc gYH2rdSipbz8jrJlSEx+T+b5LI3fnFSjnyElBl6heX5UuD+QWX+U3E+6Fm01 wA3qOZB4f7shFsmy+CMR1x+3Z+HXVoxbIGX7uGfX4tDGhsLECDUWoI7JcGXZ CHhBUCq816xEnlbuW4vYrT1twMhvii/THb+42DWrNhddlHIilQLJngX5APKd rBA24mtMZBFflxFfl4R7Wbg/mfj62cPXLyQZAD2/iv4LUueF/53nCC6/ITw0 9P0uTQMSfX9QoVnxVFq4Vwh9tC2KwBrV0HeF0JcR7p+0scbOT7CIezJNNwp9 T0v0/UXrsu2e8tAui0X3b16YKURe0BC5BSM4SGBeZwIzSjkMINNUBv9rnOqq 6NgAyB6Nbc1gAOuq0yXRuVlDcJb0Ux3HOxO0qWtsWoc9L2jJqdlPDDNGcAGp r3OUwqxpX5qxSfekUjyQU7qhFOh9it14V1vs494S9oaHrDErBT/XWxnLsrZZ 41Zme8Yal4ayAUHZydqtOXz43PO9PDzQmcQLxG+PaCe5fKT4lXT5wJ/kTcmt fP4H9Lvuta4Dz/8M8P8ol2b2qfN/5RJ//23fnbcPz//8D9fkrdO9jjNNcQ+n j6425fFfFVODzgSrb3qtd4znUz0YS+rRcT8h/DslA3BgpKFjtdUmRmmk78ZQ 8BkKi0T3HGGKn3Kh0pU6X6D3MqqU8crboCr2IasM2DVfo8/HcIK5WyZkEMS+ DKY4CWxuNmpOo+0Fs+TiJ+meJI//kJoe+2yGH1LPwqXKXvYcDrHjfz9IPlYx ymx2n+WCl2ijmIQ00nSJN5JszoUmM/TCp+z+V1zmZKwyRxVdf6zVoc/UYNMC HeN2YSA1ZI4f0nNi42ZMcDP88GqBZrVjG7X56iCzrE0GGWg90aTYtnOPl0L1 5+1D91X3PHywYhc21RSiB3YI1BWNGMfhVqGOoEwaCbXThvlAkp9LQTBhBsX4 HnpUblhgldOpMjHfoHID0ONyu5KMLKCoqL0droAiPFN9nfojy8dqRbuHRDWq mHigevD+qvzQEprY9zakLWEKo9thuKmuHCacoXuYun/EC0iaU0ReQyLn6W3R XnGWG/CnXCqXZ20MV4VRKNT3tNYKZkQ9bgRWT3WzLzkaMqAvNrZjzYiyGcpV ORSfUW87fv4oL9kXIOlMBE21IECKsqtN0EYpUC0G0A0QOC8pXLS9REW73oJR jo/Wl2sOvgGygVjp2oUgXWuN1foaUJZ25QqR7w7b89U7Zmc18g9OtamivKCK ucGdP7CwsEQkh04gvkJY6kZWd2B+3j6Sy/E8PzzTPbyG1/AaXlvg+geC3LfL AHwAAA== ---559023410-1538048050-944180055=:2058-- From mal@lemburg.com Fri Dec 3 09:30:55 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 03 Dec 1999 10:30:55 +0100 Subject: [DB-SIG] Oracle tables encapsulation References: Message-ID: <38478DCF.7A0D3881@lemburg.com> Stuart 'Zen' Bishop wrote: > > I've attached some code I've been playing with. > ... > > Its currently Oracle specific, since there is no generic method of > binding parameters that I know of making it rather difficult to write > cross platform database stuff using Python at the moment. What about cursor.execute('select * from MyTable where id=?',(1,)) ? Or did you mean the parameter marks in the SQL statement ? Note that DBAPI 2.0 compatible interfaces will provide a flag that indicates what mark to use: paramstyle. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 28 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From cjackson@mail.waco.isd.tenet.edu Fri Dec 3 19:18:28 1999 From: cjackson@mail.waco.isd.tenet.edu (root) Date: Fri, 03 Dec 1999 13:18:28 -0600 Subject: [DB-SIG] update where current of Message-ID: <38481784.A65E5E28@mail.waco.isd.tenet.edu> Hey gang, Is it possible to do the following code w/Python and informixdb? update sometable set somecolumn = "some value" where current of THIS_HERE_CURSOR It's the THIS_HERE_CURSOR that I can't figure out how to address. Thanks Chuck Jackson Unix SysAdmin/InformixDB Waco ISD Waco, TX From sjturner@ix.netcom.com Fri Dec 3 21:21:59 1999 From: sjturner@ix.netcom.com (Stephen J. Turner) Date: Fri, 03 Dec 1999 16:21:59 -0500 Subject: [DB-SIG] update where current of References: <38481784.A65E5E28@mail.waco.isd.tenet.edu> Message-ID: <38483477.AC38FE23@ix.netcom.com> This is a multi-part message in MIME format. --------------1F06F5647D70875CDF56B84C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chuck Jackson wrote: > Is it possible to do the following code w/Python and informixdb? > > update sometable > set somecolumn = "some value" > where current of THIS_HERE_CURSOR > > It's the THIS_HERE_CURSOR that I can't figure out how to address. At first, I was going to say "no," since the DB-API spec doesn't appear to address positioned UPDATEs and DELETEs -- only searched ones. Then I started digging, and the answer surprised me. It turns out it _is_ possible, though technically it's a cheat, since it (a) is nonportable to any other DB-API implementation, and (b) requires that you know how informixdb generates cursor IDs. Attached is a contrived example showing how to do it. The magic is in the construction of the positioned UPDATE statement: "update ... where current of CUR%lX" % id(cursor) Perhaps a future revision to the DB-API spec should add a read-only 'name' attribute to cursor objects, so that this could be done more portably as: "update ... where current of %s" % cursor.name Thoughts, anyone? -- Stephen J. Turner --------------1F06F5647D70875CDF56B84C Content-Type: text/plain; charset=us-ascii; name="ifxposupd.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ifxposupd.py" import string # connect to the database import informixdb db = informixdb.informixdb('stores7') # allocate cursor and statement objects cur = db.cursor() stmt = db.cursor() # create the positioned update string update = 'update orders set backlog=? where current of CUR%lX' % id(cur) # open an updateable cursor cur.execute('select backlog from orders for update') while 1: row = cur.fetchone() if not row: break backlog, = row # toggle the case of the backlog column and update in place backlog = string.swapcase(backlog) stmt.execute(update, (backlog,)) --------------1F06F5647D70875CDF56B84C-- From cjackson@mail.waco.isd.tenet.edu Fri Dec 3 23:04:07 1999 From: cjackson@mail.waco.isd.tenet.edu (root) Date: Fri, 03 Dec 1999 17:04:07 -0600 Subject: [DB-SIG] update where current of References: <38481784.A65E5E28@mail.waco.isd.tenet.edu> <38483477.AC38FE23@ix.netcom.com> Message-ID: <38484C67.BC51FE5E@mail.waco.isd.tenet.edu> Many thanks!! I just got it to work interactively. I don't know that I would have thought of the 2 cursor approach. Also, I've never seen 'id()' before (I'm a python newbie) but I figured that kind of approach would be the track I'd have to take. I wrote a simple gui 'isql'-like program in perl/tk and since my conversion I've been trying to rewrite it in python/tkinter/pmw. Actually the "update...where current of ..." has nothing to do with the said program; I'm just trying to also port some 4GL programs I've written. I hope to see if I can gui-fy some stuff w/o resorting to 4J's/Dynamic 4GL. Thanks! Chuck Jackson Waco, TX "Stephen J. Turner" wrote: > Chuck Jackson wrote: > > Is it possible to do the following code w/Python and informixdb? > > > > update sometable > > set somecolumn = "some value" > > where current of THIS_HERE_CURSOR > > > > It's the THIS_HERE_CURSOR that I can't figure out how to address. > > At first, I was going to say "no," since the DB-API spec doesn't appear > to address positioned UPDATEs and DELETEs -- only searched ones. Then I > started digging, and the answer surprised me. It turns out it _is_ > possible, though technically it's a cheat, since it (a) is nonportable > to any other DB-API implementation, and (b) requires that you know how > informixdb generates cursor IDs. > > Attached is a contrived example showing how to do it. The magic is in > the construction of the positioned UPDATE statement: > "update ... where current of CUR%lX" % id(cursor) > > Perhaps a future revision to the DB-API spec should add a read-only > 'name' attribute to cursor objects, so that this could be done more > portably as: > "update ... where current of %s" % cursor.name > > Thoughts, anyone? > > -- > Stephen J. Turner > > ------------------------------------------------------------------------ > import string > > # connect to the database > import informixdb > db = informixdb.informixdb('stores7') > > # allocate cursor and statement objects > cur = db.cursor() > stmt = db.cursor() > > # create the positioned update string > update = 'update orders set backlog=? where current of CUR%lX' % id(cur) > > # open an updateable cursor > cur.execute('select backlog from orders for update') > while 1: > row = cur.fetchone() > if not row: > break > backlog, = row > > # toggle the case of the backlog column and update in place > backlog = string.swapcase(backlog) > stmt.execute(update, (backlog,)) From mal@lemburg.com Fri Dec 3 23:43:14 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 04 Dec 1999 00:43:14 +0100 Subject: [DB-SIG] update where current of References: <38481784.A65E5E28@mail.waco.isd.tenet.edu> <38483477.AC38FE23@ix.netcom.com> Message-ID: <38485592.F05AABDD@lemburg.com> "Stephen J. Turner" wrote: > > Chuck Jackson wrote: > > Is it possible to do the following code w/Python and informixdb? > > > > update sometable > > set somecolumn = "some value" > > where current of THIS_HERE_CURSOR > > > > It's the THIS_HERE_CURSOR that I can't figure out how to address. > > At first, I was going to say "no," since the DB-API spec doesn't appear > to address positioned UPDATEs and DELETEs -- only searched ones. Then I > started digging, and the answer surprised me. It turns out it _is_ > possible, though technically it's a cheat, since it (a) is nonportable > to any other DB-API implementation, and (b) requires that you know how > informixdb generates cursor IDs. > > Attached is a contrived example showing how to do it. The magic is in > the construction of the positioned UPDATE statement: > "update ... where current of CUR%lX" % id(cursor) > > Perhaps a future revision to the DB-API spec should add a read-only > 'name' attribute to cursor objects, so that this could be done more > portably as: > "update ... where current of %s" % cursor.name > > Thoughts, anyone? There was some discussion about this when we thought up the 2.0 of the spec. It turned out that named cursors are probably not portable and thus the requirement to be able to name the cursor or query its name was dropped. FYI, mxODBC has APIs for naming cursors and querying the name even if it was not named: cursor.setcursorname(name) Sets the name to be associated with the with the cursor object. There is a length limit for names in SQL at 18 characters. An InternalError will be raised if the name is too long or otherwise not useable. cursor.getcursorname() Returns the current cursor name associated with the cursor object. This may either be the name given to the cursor at creation time or a name generated by the ODBC driver for it to use. and connection.cursor([name]) Constructs a new Cursor Object with the given name using the connection. If no name is given, the ODBC driver will determine a unique name on its own. You can query this name with cursor.getcursorname(). -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 28 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From zen@cs.rmit.edu.au Mon Dec 6 00:54:27 1999 From: zen@cs.rmit.edu.au (Stuart 'Zen' Bishop) Date: Mon, 6 Dec 1999 11:54:27 +1100 (EST) Subject: [DB-SIG] Oracle tables encapsulation In-Reply-To: <38478DCF.7A0D3881@lemburg.com> Message-ID: On Fri, 3 Dec 1999, M.-A. Lemburg wrote: > Stuart 'Zen' Bishop wrote: > > > > I've attached some code I've been playing with. > > ... > > > > Its currently Oracle specific, since there is no generic method of > > binding parameters that I know of making it rather difficult to write > > cross platform database stuff using Python at the moment. > > What about cursor.execute('select * from MyTable where id=?',(1,)) ? > Or did you mean the parameter marks in the SQL statement ? Note > that DBAPI 2.0 compatible interfaces will provide a flag that > indicates what mark to use: paramstyle. Yes - I meant the parameter marks in the SQL statement. The best solution I can come up with would be a module which provides a thin level of abstraction to DBAPI 2.0 interfaces. Initial implementation could be identical to DBAPI 2.0, except that the connect method would require a DBAPI module name. Advantages - common autocommit mode common paramstyles common thread safety (if the driver doesn't support the required level, a seperate thread could be spawned and all transactions are passed to this thread for execution. Or it could just throw an exception if calls are made from unsupported threads if we are feeling lazy). ability to write 'generic' SQL and distribute product where the end user can easily select the DBMS ability to fatten the API with useful helper functions, without requiring everyone to reinvent their wheels or cut&paste code Could be incorporated into the python distribution, possibly with Gadfly or PostgreSQL if the licences are compatible. A generic Zope DA could possibly be written to have Zope support more databases. -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen From adustman@comstar.net Mon Dec 6 20:49:01 1999 From: adustman@comstar.net (Andy Dustman) Date: Mon, 6 Dec 1999 15:49:01 -0500 (EST) Subject: [DB-SIG] Mysql insert_id() questions In-Reply-To: Message-ID: On Thu, 2 Dec 1999, Andrew Diller wrote: > > Hello: > > I'm trying to grab the auto_increment value of my most recent insert. The > MySQL manuals and the MySQLdb both mention the mysql_insert.id() which > does exactly this. > > I'm getting an error though, in my cgi code: > > ------------------ > > db = MySQLdb.Connection(db='example', user='test', passwd='dontlook'); > cursor = db.cursor() > > .... sometime later: > > cursor.execute("INSERT into database some stuff") > > recordKey = db.insert_id() > > > > > I get an attribute error on the assignment: > > > File "/usr/local/apache/htdocs/usginfo/incident.py", line 142, in > ProcessForm > recordKey = db.insert_id() > AttributeError: insert_id > > > Does anyone have a sucessful code snippet to retreive this value from > MySQL? You actually need: recordKey = db.db.insert_id() insert_id() is a method of a _mysql connection, which is stored in the MySQLdb.Connection() as db. Keep in mind that all the methods listed in the table in big table (MySQL C API function mapping) in the MySQLdb docs are methods of various _mysql objects, which is not a DB API interface (supplied by MySQLdb). The documentation on this methods is intentionally vague, but should be fairly obvious if you have the standard MySQL docs. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d "Therefore, sweet knights, if you may doubt your strength or courage, come no further, for death awaits you all, with nasty, big, pointy teeth!" From reto.griesser@winterthur.ch Tue Dec 7 10:30:28 1999 From: reto.griesser@winterthur.ch (Griesser Reto) Date: Tue, 7 Dec 1999 11:30:28 +0100 Subject: [DB-SIG] IBM DB2 Message-ID: <723D2B0FCE36D311994100508B0965D901658F74@c010272.winterthur.ch> Hi I'm new to Python and i'm looking for an API for IBM DB2. How can I connect to a DB2-Database directly, not over ODBC? Is for that some software needed, avaliable? Thanks in advance :-) Reto From mal@lemburg.com Tue Dec 7 10:54:02 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 07 Dec 1999 11:54:02 +0100 Subject: [DB-SIG] IBM DB2 References: <723D2B0FCE36D311994100508B0965D901658F74@c010272.winterthur.ch> Message-ID: <384CE74A.7B9F2B3B@lemburg.com> Griesser Reto wrote: > > Hi > > I'm new to Python and i'm looking for an API for IBM DB2. > How can I connect to a DB2-Database directly, not over ODBC? > > Is for that some software needed, avaliable? You could take mxODBC and link against the IBM CLI libs. AFAIK, there is no supported native interface to DB2. Long ago there was an interface lib which you could use directly, but IBM put the EmbeddedSQL precompiler on top of it, hiding it rather well from general exposure. Hope that helps, -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 24 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From petrilli@amber.org Tue Dec 7 15:47:25 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Tue, 7 Dec 1999 10:47:25 -0500 Subject: [DB-SIG] IBM DB2 In-Reply-To: <384CE74A.7B9F2B3B@lemburg.com>; from mal@lemburg.com on Tue, Dec 07, 1999 at 11:54:02AM +0100 References: <723D2B0FCE36D311994100508B0965D901658F74@c010272.winterthur.ch> <384CE74A.7B9F2B3B@lemburg.com> Message-ID: <19991207104725.A15697@trump.amber.org> M.-A. Lemburg [mal@lemburg.com] wrote: > Griesser Reto wrote: > > > > Hi > > > > I'm new to Python and i'm looking for an API for IBM DB2. > > How can I connect to a DB2-Database directly, not over ODBC? > > > > Is for that some software needed, avaliable? > > You could take mxODBC and link against the IBM CLI libs. AFAIK, > there is no supported native interface to DB2. Long ago there > was an interface lib which you could use directly, but IBM > put the EmbeddedSQL precompiler on top of it, hiding it rather well > from general exposure. IBM's official position is that CLI is the "native interface" in the newer releases. They also have an "administrative API" which gives you access too all kinds of underlying admin stuff (like destroying and managing tablespace on disk, replicating databases, etc). Chris -- | Christopher Petrilli | petrilli@amber.org From jimbag@kw.igs.net Fri Dec 10 02:59:57 1999 From: jimbag@kw.igs.net (JB) Date: Thu, 09 Dec 1999 21:59:57 -0500 Subject: [DB-SIG] Posgres DBI Message-ID: <38506CAD.E744D630@kw.igs.net> Hi all. I just joined the list because I read thru the archives and noted some discussion a few months back about the Postgres DBI module. I wondered if that is off the ground and if I can be of any assistance? I started to code that today but thought I should check to see if anyone else was on it. And sure enough. Let me know if I can help. cheers jim From db-sig@python.org Sat Dec 11 12:53:00 1999 From: db-sig@python.org (D'Arcy J.M. Cain) Date: Sat, 11 Dec 1999 07:53:00 -0500 (EST) Subject: [DB-SIG] Posgres DBI In-Reply-To: <38506CAD.E744D630@kw.igs.net> from JB at "Dec 9, 1999 09:59:57 pm" Message-ID: Thus spake JB > Hi all. I just joined the list because I read thru the archives and > noted some discussion a few months back about the Postgres DBI module. I > wondered if that is off the ground and if I can be of any assistance? I > started to code that today but thought I should check to see if anyone > else was on it. And sure enough. Let me know if I can help. Not sure if that was me but I do want to add that to PyGreSQL. We started discussing it on the mailing list but is stalled and I got really busy for a while and haven't been able to follow up. I should have time to start pushing it again after Christmas but check out where we are now. http://www.druid.net/pygresql/. To get on the mailing list go to http://www.vex.net/mailman/listinfo/pygresql. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From tbryan@server.python.net Wed Dec 15 17:23:52 1999 From: tbryan@server.python.net (Tom Bryan) Date: Wed, 15 Dec 1999 12:23:52 -0500 (EST) Subject: [DB-SIG] DCOracle on DEC Alpha with Oracle 8.1.5 In-Reply-To: Message-ID: I'd like to build the DCOracle extension to Python on a DEC Alpha, running OSF1 V4.0F. The machine has Oracle 8.1.5 on it. Has anyone had success with DCOracle-1.3.0 on a DEC Alpha? I had two problems with the build, and I thought that I ask here first before I start modifying the sources... For some reason, the compilation is trying to include both ocikpr.h and ociapr.h (K&R and ANSI versions of the same header), but I don't wee where these files are being included. It leads to errors with multiply ders from multiply declared prototypes. I also get the following warning, which sounds like it's an architecture problem, just before the build exits with error. Before I proceed, has anyone already solved these problems? cc: Warning: ./oci_.c, line 2595: In this statement, the referenced type of the pointer value "&output_string_dim1" is "long", which is not compatible with "int ". (ptrmismatch) _arg5=&output_string_dim1; output_string_dim1=256; Thanks, ---Tom P.S. For those who are curious, we do C++ development with an Oracle back-end at work. I would like to have a simple yet powerful (i.e., not C++ and not PL/SQL) language for use in writing test code and prototypes. Python is, of course, my language of choice for this task. From egabriel@io.com Wed Dec 15 20:40:33 1999 From: egabriel@io.com (Gabriel) Date: Wed, 15 Dec 1999 14:40:33 -0600 (EST) Subject: [DB-SIG] IBM DB2 Message-ID: Hey, all. I know that DB2 support has been addressed before. I have just gotten the go ahead to push forward on a large project, and I started in Postgresql, but it seems that for companywide acceptance I need to use DB2. If anyone has even a start on a DB2 module, or some alpha code lying about, I'd like to have a look; if I am able to get it up and running, even if it means some major hacking, I'd give it a shot. All that is required is [Bthe most basic functionality: do a query and return a result like pygresql. The DB-API would be even better :) Thanks... if I am able to get this working we could all benefit. -Gabriel From petrilli@amber.org Wed Dec 15 20:45:52 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Wed, 15 Dec 1999 15:45:52 -0500 Subject: [DB-SIG] IBM DB2 In-Reply-To: ; from egabriel@io.com on Wed, Dec 15, 1999 at 02:40:33PM -0600 References: Message-ID: <19991215154552.G18015@trump.amber.org> Gabriel [egabriel@io.com] wrote: > > If anyone has even a start on a DB2 module, or some alpha code lying > about, I'd like to have a look; if I am able to get it up and running, > even if it means some major hacking, I'd give it a shot. > > All that is required is [Bthe most basic functionality: do a query and > return a result like pygresql. The DB-API would be even better :) > > Thanks... if I am able to get this working we could all benefit. Mark Lemburg's mxODBC has some stuff for linking with DB2 libraries, so this should work (DB2 uses X/Open CLI, which si almos the same as ODBC). Chris -- | Christopher Petrilli | petrilli@amber.org From steinme@norway.eu.net Wed Dec 22 00:00:53 1999 From: steinme@norway.eu.net (Stein M. Eliassen) Date: Wed, 22 Dec 1999 01:00:53 +0100 Subject: [DB-SIG] MySQLdb build error Message-ID: <386014B5.3AFAF44E@norway.eu.net> Hi, I'm trying to build MySQLdb 0.1.1 on a Slackware 7.0 box with MySQL 3.22.27 and this is the result: . . . gcc -shared _mysqlmodule.o -L/usr/local/lib/mysql/ -lmysqlclient -o _mysqlmodule.so Traceback (innermost last): File "build.py", line 14, in ? import MySQLdb File "MySQLdb.py", line 19, in ? from _mysql import * ImportError: libmysqlclient.so.6: cannot open shared object file: No such file or directory I have checked and libmysqlclient.so.6 is in /usr/local/lib/mysql and MySQL is working since I'm able to use the database with mysqld. Is there something I have to do with the mysql configuration? How do I test that libmysqlclient.so.6 is working? Thanks, Stein From George Thom@s" Hi everyone, I am not sure if this is the right forum, but here goes. I have been using the win32 ODBC module that ships with the 1.5.2 distribution. Using installed proprietary ODBC drivers I have been exploiting the module in very elementary ways as part of larger applications. Having used this with Microsoft SQL Server, MySQL and Oracle with databases created with the same schema and containing the same data I noticed that the output obtained when interfacing with the ODBC driver provided with Oracle 8i, integers are returned with the L (long) suffix. This does not usually make for pleasant viewing if this data has to be displayed :-) Does anyone know where the problem lies and what a good solution would be ? Once again, all apologies if this does not seem the right place to pose this query, Regards and thanks in advance, George -------------------------------------------------------------------------- George Thomas Resident,Planet Earth,Third Rock from the Sun georgethomas@pspl.co.in Flat No. FI-5, Fifth Floor, Himagirinath Co-op. Hsg. Society, 486A Elphinstone Road, Kirkee, Pune - 411003, Maharashtra State, India. -------------------------------------------------------------------------- From infotechsys@pivot.net Wed Dec 22 01:59:45 1999 From: infotechsys@pivot.net (Wayne) Date: Tue, 21 Dec 1999 20:59:45 -0500 Subject: [DB-SIG] Help installing PyGreSQL. Message-ID: <38603091.FF81F06F@pivot.net> Hello, I'm running postgreSQL 6.4.2 and would like to install PyGresSQL. In the install instruction it refers to a file name "Makefile.pre.in boot" I don't have this file file on my system. There is also a refers to a directory called "??/Modules" . I don't have a Modules directory. There is a refers to the Setup files, is this the directory where make is for postgreSQL. The distro I have is Redhat 6.0. TIA. Wayne From tbryan@server.python.net Thu Dec 23 14:30:05 1999 From: tbryan@server.python.net (Tom Bryan) Date: Thu, 23 Dec 1999 09:30:05 -0500 (EST) Subject: [DB-SIG] Help installing PyGreSQL. In-Reply-To: <38603091.FF81F06F@pivot.net> Message-ID: On Tue, 21 Dec 1999, Wayne wrote: > Hello, I'm running postgreSQL 6.4.2 and would like to install > PyGresSQL. In the install instruction it refers to a file name > "Makefile.pre.in boot" I don't have this file file on my system. There > is also a refers to a directory called "??/Modules" . I don't have a > Modules directory. There is a refers to the Setup files, is this the > directory where make is for postgreSQL. The distro I have is Redhat > 6.0. I haven't installed PyGresSQL, but what you're describing sounds like the Python source tree. If you build Python from source, the Modules subdirectory of the source code directories contains a Setup file, where you can select, for example, whether to build the Python interpreter with support for Tk, gdbm, and zlib. With many packages, it is sufficient to compile a shared library (a .so file) and put it in /usr/lib/site-python (on RedHat 6.0). If you're just trying to follow the instructions, it will make the most sense if you build Python by yourself from the sources. Download and unpack py152.tgz from www.python.org. If you need a Setup file for RedHat, just e-mail me. The files you need are available on RedHat, but they are spread around in multiple directories. If you don't want to mess around with building Python from source, you'll need (at least) the python-devel rpm. (Do a rpm -ql python-devel to see where the files like Makefile.pre.in are located.) By the way, RedHat comes with Python-1.5.1. The current version is Python-1.5.2. You might want to grab the latest RPMs from Olivier Andrich's page on the Starship http://starship.python.net ---Tom From db-sig@python.org Thu Dec 23 18:07:54 1999 From: db-sig@python.org (D'Arcy J.M. Cain) Date: Thu, 23 Dec 1999 13:07:54 -0500 (EST) Subject: [DB-SIG] Help installing PyGreSQL. In-Reply-To: from Tom Bryan at "Dec 23, 1999 09:30:05 am" Message-ID: Thus spake Tom Bryan > On Tue, 21 Dec 1999, Wayne wrote: > > > Hello, I'm running postgreSQL 6.4.2 and would like to install > > PyGresSQL. In the install instruction it refers to a file name > > "Makefile.pre.in boot" I don't have this file file on my system. There > > is also a refers to a directory called "??/Modules" . I don't have a > > Modules directory. There is a refers to the Setup files, is this the > > directory where make is for postgreSQL. The distro I have is Redhat > > 6.0. Ah, that's the info missing from your email to me that I asked for. :-) (you == wayne) > I haven't installed PyGresSQL, but what you're describing sounds like the > Python source tree. If you build Python from source, the Modules > subdirectory of the source code directories contains a Setup file, where That's right. The README is for building from full source. > By the way, RedHat comes with Python-1.5.1. The current version is > Python-1.5.2. You might want to grab the latest RPMs from Olivier > Andrich's page on the Starship http://starship.python.net And the latest (ftp://ftp.druid.net/pub/distrib/PyGreSQL-beta.tgz) PyGreSQL beta has a config file for building RPMs if someone on Linux wants to build it and make it available. I run NetBSD so I can't do it here. I would be willing to make it available on the PyGreSQL site though, either as a file or a link to the file on your system. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From brunson@level3.net Thu Dec 23 18:31:48 1999 From: brunson@level3.net (Eric Brunson) Date: Thu, 23 Dec 1999 11:31:48 -0700 Subject: [DB-SIG] DCOracle Message-ID: <38626A94.93C16E7F@level3.net> I've just started using DCOracle, and I'm *fairly* new to python, been using it on and off for about 4 months, but I'm having some problems with DCOracle and I haven't found many resources on the web for docs or code examples. I'm using version 1.3.0 of the DCOracle module and I'm trying to use the Handle object. Perhaps I'm misunderstanding the usage, but I inferred from the description that it's usage was kinda like pre- compiling a regex that you're going to use over and over. I.e. dbHndl = dbConn.prepare( "select somefield "from sometable " "where thekey = :p1" ) for key in keys dbHndl.execute( (key,) ) values = dbHndl.fetchone() Am I off base here? In any case, when I try to do this, the first time through the loop it works, but the second time, I get a NameError on dbHndl. That's my most important problem... A more minor annoyance is that I cannot seem to find where the OracleError exception is defined. I want to be able to catch the specific exception then parse the Oracle error string, but the only way I've been able to catch it is with a default except: clause. Sys.exc_type is set to OracleError but trying to catch OracleError, DCOracle.OracleError, DCOracle.dbiUtil.OracleError, etc. all miss it. And finally, any pointers to code examples, especially ones using some of the more esotheric features of the module, would be appreciated. Thanks, e. P.S. I'm still waiting for my subscription to the list to become active, so could any responses be copied to this return address. Thanks again. -- Eric Brunson * _ o * brunson@brunson.com * / //\ Faster and faster, brunson@l3.net \>>| * until the thrill of speed \\, overcomes the fear of death From tbryan@server.python.net Thu Dec 23 19:47:14 1999 From: tbryan@server.python.net (Tom Bryan) Date: Thu, 23 Dec 1999 14:47:14 -0500 (EST) Subject: [DB-SIG] Help installing PyGreSQL. In-Reply-To: Message-ID: On Thu, 23 Dec 1999, D'Arcy J.M. Cain wrote: > > By the way, RedHat comes with Python-1.5.1. The current version is > > Python-1.5.2. You might want to grab the latest RPMs from Olivier > > Andrich's page on the Starship http://starship.python.net > > And the latest (ftp://ftp.druid.net/pub/distrib/PyGreSQL-beta.tgz) > PyGreSQL beta has a config file for building RPMs if someone on Linux > wants to build it and make it available. I run NetBSD so I can't do > it here. I would be willing to make it available on the PyGreSQL site > though, either as a file or a link to the file on your system. I'll probably download the sources to the Python Starship tonight and try to make the RPM. I'll e-mail you later with an ftp address if I'm successful. (Otherwise, I'll e-mail you with complaints. ;-) Since Red Hat ships with Python and PostgreSQL, perhaps they'd be willing to put PyGreSQL RPMs on their next CD. ---Tom From db-sig@python.org Thu Dec 23 20:29:25 1999 From: db-sig@python.org (D'Arcy J.M. Cain) Date: Thu, 23 Dec 1999 15:29:25 -0500 (EST) Subject: [DB-SIG] Help installing PyGreSQL. In-Reply-To: from Tom Bryan at "Dec 23, 1999 02:47:14 pm" Message-ID: Thus spake Tom Bryan > I'll probably download the sources to the Python Starship tonight and try > to make the RPM. I'll e-mail you later with an ftp address if I'm Cool. > successful. (Otherwise, I'll e-mail you with complaints. ;-) Not me. :-) I know nothing about RPMs. However, the author of that config is listed in the file I think. I would like to know if there are any problems though. > Since Red Hat ships with Python and PostgreSQL, perhaps they'd be willing > to put PyGreSQL RPMs on their next CD. That would be great. Maybe we'll have 3.0 by then. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From infotechsys@pivot.net Wed Dec 22 11:53:04 1999 From: infotechsys@pivot.net (Wayne) Date: Wed, 22 Dec 1999 06:53:04 -0500 Subject: [DB-SIG] Help installing PyGreSQL. References: Message-ID: <3860BBA0.5622D4FF@pivot.net> Hi, PostgreSQL 6.4.2 and Python 1.5.1 are already installed on my system. So, what do I have to do to get PyGreSQL installed? Wayne :wq D'Arcy J.M. Cain wrote: > Thus spake Tom Bryan > > On Tue, 21 Dec 1999, Wayne wrote: > > > > > Hello, I'm running postgreSQL 6.4.2 and would like to install > > > PyGresSQL. In the install instruction it refers to a file name > > > "Makefile.pre.in boot" I don't have this file file on my system. There > > > is also a refers to a directory called "??/Modules" . I don't have a > > > Modules directory. There is a refers to the Setup files, is this the > > > directory where make is for postgreSQL. The distro I have is Redhat > > > 6.0. > > Ah, that's the info missing from your email to me that I asked for. :-) > (you == wayne) > > > I haven't installed PyGresSQL, but what you're describing sounds like the > > Python source tree. If you build Python from source, the Modules > > subdirectory of the source code directories contains a Setup file, where > > That's right. The README is for building from full source. > > > By the way, RedHat comes with Python-1.5.1. The current version is > > Python-1.5.2. You might want to grab the latest RPMs from Olivier > > Andrich's page on the Starship http://starship.python.net > > And the latest (ftp://ftp.druid.net/pub/distrib/PyGreSQL-beta.tgz) PyGreSQL > beta has a config file for building RPMs if someone on Linux wants to > build it and make it available. I run NetBSD so I can't do it here. I > would be willing to make it available on the PyGreSQL site though, either > as a file or a link to the file on your system. > > -- > D'Arcy J.M. Cain | Democracy is three wolves > http://www.druid.net/darcy/ | and a sheep voting on > +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From mwa@gate.net Thu Dec 23 20:33:11 1999 From: mwa@gate.net (Mark W. Alexander) Date: Thu, 23 Dec 1999 15:33:11 -0500 (EST) Subject: [DB-SIG] Help installing PyGreSQL. In-Reply-To: Message-ID: I did a PyGreSQL RPM some time ago. If you need any help, email me and I'll try to kickstart my memory. Mark Alexander mwa@gate.net On Thu, 23 Dec 1999, D'Arcy J.M. Cain wrote: > Date: Thu, 23 Dec 1999 15:29:25 -0500 (EST) > From: D'Arcy J.M. Cain > Reply-To: db-sig@python.org > To: Tom Bryan > Cc: infotechsys@pivot.net, db-sig@python.org > Subject: Re: [DB-SIG] Help installing PyGreSQL. > > Thus spake Tom Bryan > > I'll probably download the sources to the Python Starship tonight and try > > to make the RPM. I'll e-mail you later with an ftp address if I'm > > Cool. > > > successful. (Otherwise, I'll e-mail you with complaints. ;-) > > Not me. :-) I know nothing about RPMs. However, the author of that > config is listed in the file I think. I would like to know if there > are any problems though. > > > Since Red Hat ships with Python and PostgreSQL, perhaps they'd be willing > > to put PyGreSQL RPMs on their next CD. > > That would be great. Maybe we'll have 3.0 by then. > > -- > D'Arcy J.M. Cain | Democracy is three wolves > http://www.druid.net/darcy/ | and a sheep voting on > +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > From tbryan@server.python.net Fri Dec 24 02:06:43 1999 From: tbryan@server.python.net (Tom Bryan) Date: Thu, 23 Dec 1999 21:06:43 -0500 (EST) Subject: [DB-SIG] Help installing PyGreSQL. In-Reply-To: <3860BBA0.5622D4FF@pivot.net> Message-ID: On Wed, 22 Dec 1999, Wayne wrote: > Hi, PostgreSQL 6.4.2 and Python 1.5.1 are already installed on my > system. So, what do I have to do to get PyGreSQL installed? Wayne I'm not currently running PostgreSQL; therfore, I haven't tested the module that I made. E-mail me if this doesn't work for you: Install the python-devel RPM if necessary. To check whether you have the python-devel RPM, run this command rpm -qi python-devel You'll get "package python-devel is not installed" if you don't have it. Download PyGreSQL.tgz tar xzvf PyGreSQL.tgz cd PyGreSQL-2.4 # either remove the '\', and put the next two lines on one line # or make sure that you press enter immediately after the '\' gcc -fpic -shared -o _pg.so -I/usr/include/pgsql/ \ -I/usr/include/python1.5/ pgmodule.c -lpq -lcrypt Now test the module as recommended in the README.linux file that comes with PyGreSQL-2.4. If it works, su to root. The move the _pg.so, pg.py, and pgsqldb.py files to /usr/lib/site-python/. exit from the root account. Now, rerun the test in any directory other than /usr/lib/site-python/, and it should still work. ---Tom One of the Starship Python Sys Admins From hniksic@iskon.hr Fri Dec 24 12:33:05 1999 From: hniksic@iskon.hr (Hrvoje Niksic) Date: 24 Dec 1999 13:33:05 +0100 Subject: [DB-SIG] fetchone() as fetchall() Message-ID: <9t9d7rwplha.fsf@mraz.iskon.hr> I've often found fetchall() convenient to use simply because I could write something like: for entid, userid in cursor.fetchall(): ... The same thing written with fetchone() would look like this: while 1: row = cursor.fetchone() if row is None: break entid, userid = row ... That's *five* lines of code replacing one line. However, when retrieving large datasets, especially in long-running programs, using fetchall() is often not acceptable. Here is a small wrapper class that enables you to use fetchone() as if it were fetchall. It is quite trivial, but I'd still like to contribute it to whoever might be interested. class FetchAll: def __init__(self, cursor): self.__cursor = cursor def __getitem__(self, index): # The indices had better be in order, because we're not # wasting time checking them. result = self.__cursor.fetchone() if result is not None: return result else: raise IndexError Given the above example, the usage looks like this: for entid, userid in FetchAll(cursor): ... Feel free to incorporate the class in your programs. I hope someone finds it useful. From infotechsys@pivot.net Tue Dec 28 11:22:43 1999 From: infotechsys@pivot.net (Wayne) Date: Tue, 28 Dec 1999 06:22:43 -0500 Subject: [DB-SIG] Hoe to. Message-ID: <38689D83.418417B4@pivot.net> Hello, I'm trying to create a report from information stored in my postgres database. The python code looks like this- def doReport(self, event = 0): fileobj = open("testoutput", 'w') db = _pg.connect('dbname', 'localhost') myrecord = db.query('SELECT * FROM "tablename"') fileobj.write(myrecord) The error I'm getting is telling me that myrecord is a read only buffer. So, can someonr tell me how I go about writing a record to a file that is read from the database. The other part of what I'm trying to do is to print the file that I write. Is there a better way to do this than what I'm doing. Thanks for your time. Wayne From tbryan@server.python.net Thu Dec 30 01:50:01 1999 From: tbryan@server.python.net (Tom Bryan) Date: Wed, 29 Dec 1999 20:50:01 -0500 (EST) Subject: [DB-SIG] Hoe to. In-Reply-To: <38689D83.418417B4@pivot.net> Message-ID: On Tue, 28 Dec 1999, Wayne wrote: > postgres database. The python code looks like this- > > def doReport(self, event = 0): > fileobj = open("testoutput", 'w') > db = _pg.connect('dbname', 'localhost') > myrecord = db.query('SELECT * FROM "tablename"') > fileobj.write(myrecord) First of all, importing _pg directly is only necessary during initial testing. After that, you should be importing the Python program that wraps _pg, probably something named pg or pgdb. In this case, it probably isn't the problem, but it's a good idea in any case. > The error I'm getting is telling me that myrecord is a read only buffer. When asking for help, you should really just post the traceback so that we can see the entire error message. Also, tell us what you've already tried. For example, does SELECT * from "tablename" work from PostgreSQL's normal client? Are you able to call 'print myrecord'? In your case, the problem is unrelated to databases. The file object's write() method doesn't automaticaly invoke the __str__ method of an object: Python 1.5.2 (#1, Apr 18 1999, 16:03:16) [GCC pgcc-2.91.60 19981201 (egcs-1.1.1 on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> fh = open('junk','w') >>> data = 3.14 >>> print data 3.14 >>> str(data) '3.14' >>> fh.write(data) Traceback (innermost last): File "", line 1, in ? TypeError: read-only buffer, float >>> fh.write(str(data)) >>> fh.write('\n %s' % data) >>> fh.write('\n %f\n' % data) >>> fh.close() $ cat junk 3.14 3.14 3.140000 That is, make sure that you're passing a file object's write method a string by explicitly converting the argument to a string. ---Tom