From Billy G. Allie" --==_Exmh_-477308784P Content-Type: text/plain; charset=us-ascii I would like to propose the following change to the API. Instead of cursor.fetchone() returning a sequence, have it return an object of the class ResultSet. The class, ResultSet, would emulate a list object with the following additional features: 1. The class would have the column names in the result as attributes. 2. The class would act like a dictionary in that it could be indexed with a column name. 3. A copy of the cursor.description attribute is contained in the ResultSet object. (Actually, since ResultSet acts as a sequence, it could be used under DB-API 2.0) The ResultSet class would be easy to implement in Python. I have appended an implementation I am using in my DB-API 2.0 interface to PostgreSQL to the end of this message. Your comment on this proposal are welcome. class PgResultSet: def __init__(self, value, description): self.__dict__['baseObj'] = value self.__dict__['description'] = description # Now we set up attributes based on the column names in the result set for i in range(len(self.description)): exec "self.__dict__['%s'] = self.baseObj[%d]" % \ (self.description[i][0], i) return # __xlatKey transform a string (column name) key into an integer key # used to access the column data. def __xlatKey(self, key): _keys = (key, string.lower(key)) for _i in range(len(self.description)): if self.description[_i][0] in _keys: key = _i break if type(key) == types.StringType: raise NameError, key return key # We define a __setattr__ routine that will only allow the attributes that # are the column names to be updated. All other attributes are read-only. def __setattr__(self, key, value): if key in ('baseObj', 'description'): raise AttributeError, "%s is read-only." % key if self.__dict__.has_key(key): self.__dict__[key] = value else: raise NameError, key def __len__(self): return len(self.baseObj) def __getitem__(self, key): if type(key) == types.StringType: key = self.__xlatKey(key) return self.baseObj[key] def __setitem__(self, key, value): if type(key) == types.StringType: key = self.__xlatKey(key) self.baseObj[key] = value return def __getslice__(self, i, j): return PgResultSet(self.baseObj[i:j], self.description[i:j]) def __setslice__(self, i, j, value): # If we are passed a PgResultSet object, convert it to the base # sequence object for the result set. Also update the description # from the PgResultSet. if isinstance(value, PgResultSet): value = value.baseObj self.description[i:j] = value.description self.baseObj[i:j] = value return def __repr__(self): return repr(self.baseObj) def __str__(self): return str(self.baseObj) -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 | --==_Exmh_-477308784P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: gpY35UmkDcr5y8BZdNLBm5os2sWtCDR7 owGlV01vHEUQNYmQ2BV7yAGJA4dSgsku2h3ba8dJjAw4HwoLTnAwEkIbZ9Q707vb 9nzR3WN7kW9ISDlx4AcAElfOSCAOgPgLSPwArhxA4sIBqmpmdnvtCCIxipTZ6upX Va9eV48fLbx2/umnrn8sfvviYfyi+f2Try+c+/L7hc9/7nz3x/X7f3776/O/1DId b36zfP7Nhc8Gf43+Xtj+6IVHH7706o+9Hy6f+/Snl7969qF9bsnG2dKyF5uR1127 fqXryeN4/MyF7Qc308TKxHbenWRyA6w8tktZJFTyCgRjoY20m7npCBMo1ag36j04 SvMohEgdSLApZDrNUoOvYwnDNIrSI5WMaGcy4nWyb+30PN6bGCtFCOkQglybVHtD aYNxmshmC7S0uU5oswAjP8hlEsg2jMWhBGXLVRAJpIN9GVjCaNQJPIiEMfCONHlk d6X1AN6trO2ZuV2mLeM8ElZijEgZW4EdKTsu4WY1iDBUVqWJiGAoBYaXZoOqWHFD lLCcJmeTRnmcQCJiaUAlbNOcBAgDwlqtBrmVBvnoPgZHYDLMrIBQBRxdTwocYYmH gN0GyEkSymMZcuqNOuAj3OCIv4r4W2jLJkQWJ1eQHkoTaJUR+iwjUAZ9E4uNR9Qy 8yl9RYSCLW5lcyuwuYiiSRuMwk7NXKkGw8U6bXQzzw0GyDF9jai3bnRQHdD1llsE S3zMkFxmcKMUZkKSUnEWyRglS2nuTCwKCEvtFU0QWSYROySpNOpTV8HV9kDEGJ+6 i1vjiRMeDVbqoQhYtTupsSMtd+9vVxpGUMRjIpEp7K4RI2K5UX8/zTVWF3NGKRGH DsWxQOkILeFIRrheeBc17YymVW4U3IZyCL6vEmV9v2lkNGzDoYhy5M5pVwuda7To +T7pw/f7lwfCyLcH+5f3YLPYcdbFQWA35zelVLsE99IjzBIbZiHPZqIwQOhhUdW/ ituQRmrDVIOiFU3HvxnJhEtxFdfiGqhilG8AF0+lumg4Q7aWlfUXw72LsAgPcF8N zgD21V5/eQ8lxgKqFYOCXinGJeT0GA/8WxKVg0kZzDAmZWKBKIKmU1ELDiQdNew3 SofUMJKabBUS65ZWgwC77xISCis8t41lyLKPiMFF+/hisLgm/t8uU/Bw2EhNlhbm zwT6T8ygGhZEOYt9n+kgBA5HrjV8wbC+oveBluIAX/Afbrc48zk4bG7yD+Ptcl58 GTSKMFooHPD3kKPbWqeaCyoQyqnMvyua3pNEAk4RpNn3URekJt8HneaWrDzJjlQU oaqiCQgat0ymozryqfDoADlcF+LDNtAkyZB5GdKcIzj00i4K7cRqww4FmuvPNKtZ h8rjxtwiMQesBWhOj1cb5o7RtAcFOVtV1JKhi4uGBuosOgm4pInguW2V6r2xMNQs bkSFO+fRxxX3fMvI/Ed33GpRRGWljF42bSqtssLW/KaRtMrK2KWo4uaJRHPAmiur qM4DbZpl4EbnCuczMGczONWk/53ImQwcjucHyZQUE6lATnNSbdh3SXXm+hy5fbWx jzOKTY6M2HyKePO4GG7hl6A3pGFN8s7wMqG7zg1cXtNtPDHJodT82VBeYpQNMER1 NVdfQDR4yGM2zvlUmbQ8ZLzoZM4gQ53GvOBEx3NGrVF4yRorMEKTM2+7PlwGVcxL FecVV+XaY7ma+joLRN98J13PRtWbeZa1zKrj7/aPzHONO92c6dBwd6H17KZOB5n2 8aHd+JzADRx6E7jj0bRSsrDdSmP84vLw2eB1j9dej/ORl+pRo34CsHRCruR8dW11 Hd4Q2uIHRVTabqZxlhupD/Hb/er66urVdnd5fQU3dpY6Jx16KIoUepDqpA13e7B2 baW7fgJ3d+9RWI8j+3f8IrDEdCL8IyHx8IsFUZYwxvZ27zaFaq6urLbgyrVuZ+XK 2nIRnipt1P8B =NnxY -----END PGP MESSAGE----- --==_Exmh_-477308784P-- From mal@lemburg.com Tue Aug 1 09:41:25 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 01 Aug 2000 10:41:25 +0200 Subject: [DB-SIG] DB API 2.0 - dictionary fetch ? References: <200008010536.BAA25206@bajor.mug.org> Message-ID: <39868D35.6270BA49@lemburg.com> "Billy G. Allie" wrote: > > I would like to propose the following change to the API. > > Instead of cursor.fetchone() returning a sequence, have it return an object of > the class ResultSet. The class, ResultSet, would emulate a list object with > the following additional features: > > 1. The class would have the column names in the result as attributes. > 2. The class would act like a dictionary in that it could be indexed with > a column name. > 3. A copy of the cursor.description attribute is contained in the ResultSet > object. > > (Actually, since ResultSet acts as a sequence, it could be used under > DB-API 2.0) > > The ResultSet class would be easy to implement in Python. I have appended an > implementation I am using in my DB-API 2.0 interface to PostgreSQL to the end > of this message. -1 I wouldn't want to add this to the DB API spec, since writing new types in C is no fun at all and mixing C and Python is even worse. Tuples and lists are available at C level and pose no problem at all for the DB API implementor. Note that you can always add an abstraction layer on top of the DB API module in use and have it do the conversion from tuples to objects on the fly and as necessary. > Your comment on this proposal are welcome. > > class PgResultSet: > ... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bkc@murkworks.com Tue Aug 1 14:04:23 2000 From: bkc@murkworks.com (Brad Clements) Date: Tue, 1 Aug 2000 09:04:23 -0400 Subject: [DB-SIG] DB API 2.0 - dictionary fetch ? In-Reply-To: <39868D35.6270BA49@lemburg.com> Message-ID: <3986928C.1570.144B2FDC@localhost> On 1 Aug 2000, at 10:41, M.-A. Lemburg wrote: > "Billy G. Allie" wrote: > > > > I would like to propose the following change to the API. > > > > Instead of cursor.fetchone() returning a sequence, have it return an > > object of the class ResultSet. The class, ResultSet, would emulate a > > list object with the following additional features: > > > > 1. The class would have the column names in the result as attributes. 2. > > The class would act like a dictionary in that it could be indexed with > > a column name. > > 3. A copy of the cursor.description attribute is contained in the > > ResultSet > > object. > > Look for SQLDict.py, it's pretty close to this and darn nice too! Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com AOL-IM: BKClements From ldl@LDL.HealthPartners.COM Thu Aug 3 22:49:26 2000 From: ldl@LDL.HealthPartners.COM (LD Landis) Date: Thu, 3 Aug 2000 16:49:26 -0500 (CDT) Subject: [DB-SIG] DCOracle-1.3.0 try/except In-Reply-To: <20000801160117.4CECA1D2B5@dinsdale.python.org> from "db-sig-request@python.org" at Aug 01, 2000 12:01:17 PM Message-ID: <200008032149.e73LnQD26884@LDL.HealthPartners.COM> Hi, Dumb question... How do I do a "meaningful" try/except for DCOracle such that I can look at the error that was returned? I had thought that something like: try: db = DCOracle.Connect("user/password@instance.world") except DCOracle, e: print "Error", e would work, but it doesn't... Also tried using the various errors that Python catches without success... Here's what I get: Python 1.5.2 (#1, Jul 21 2000, 14:17:35) [C] on aix4 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> importr  DCOracle >>> db = DCOracle.Connect("user/password@bogus.world") Traceback (innermost last): File "", line 1, in ? File "/opt/oracle/local/lib/python1.5/DCOracle/ocidb.py", line 76, in __init__ sc=oci_8.Logon(u,p,s) OracleError: ('ORA-12154: TNS:could not resolve service name\012', 12154) >>> try: ... db = DCOracle.Connect("user/password@bogus.world") ... except OracleError: ... print "error caught" ... Traceback (innermost last): File "", line 3, in ? AttributeError: OracleError >>> try: ... db = DCOracle.Connect("user/password@bogus.world") ... except DCOracle.OracleError: ... print "error caught" ... Traceback (innermost last): File "", line 3, in ? AttributeError: OracleError >>> try: ... db = DCOracle.Connect("user/password@bogus.world") ... except DCOracle.error: ... print "caught" ... Traceback (innermost last): File "", line 2, in ? File "/opt/oracle/local/lib/python1.5/DCOracle/ocidb.py", line 76, in __init__ sc=oci_8.Logon(u,p,s) OracleError: ('ORA-12154: TNS:could not resolve service name\012', 12154) >>> try: ... db = DCOracle.Connect("user/password@bogus.world") ... except DCOracle.error, e: ... print "caught", e ... Traceback (innermost last): File "", line 2, in ? File "/opt/oracle/local/lib/python1.5/DCOracle/ocidb.py", line 76, in __init__ sc=oci_8.Logon(u,p,s) OracleError: ('ORA-12154: TNS:could not resolve service name\012', 12154) >>> print e Traceback (innermost last): File "", line 1, in ? NameError: e >>> try: ... db = DCOracle.Connect("user/password@bogus.world") ... except: ... print "Gotcha Suckers!" ... Gotcha Suckers! >>> print DCOracle.error oci.error >>> print DCOracle.error 'oci.error' >>> DCOracle.error 'oci.error' >>> ^D From mal@lemburg.com Thu Aug 3 23:25:33 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 04 Aug 2000 00:25:33 +0200 Subject: [DB-SIG] DCOracle-1.3.0 try/except References: <200008032149.e73LnQD26884@LDL.HealthPartners.COM> Message-ID: <3989F15D.648837F9@lemburg.com> LD Landis wrote: > > Hi, > > Dumb question... How do I do a "meaningful" try/except for DCOracle > such that I can look at the error that was returned? I had thought > that something like: > > try: > db = DCOracle.Connect("user/password@instance.world") > except DCOracle, e: > print "Error", e > > would work, but it doesn't... Also tried using the various errors > that Python catches without success... Here's what I get: > > Python 1.5.2 (#1, Jul 21 2000, 14:17:35) [C] on aix4 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> importr  DCOracle > >>> db = DCOracle.Connect("user/password@bogus.world") > Traceback (innermost last): > File "", line 1, in ? > File "/opt/oracle/local/lib/python1.5/DCOracle/ocidb.py", line 76, in __init__ > sc=oci_8.Logon(u,p,s) > OracleError: ('ORA-12154: TNS:could not resolve service name\012', 12154) > >>> try: > ... db = DCOracle.Connect("user/password@bogus.world") > ... except OracleError: > ... print "error caught" > ... > Traceback (innermost last): > File "", line 3, in ? > AttributeError: OracleError > >>> try: > ... db = DCOracle.Connect("user/password@bogus.world") > ... except DCOracle.OracleError: > ... print "error caught" > ... > Traceback (innermost last): > File "", line 3, in ? > AttributeError: OracleError > >>> try: > ... db = DCOracle.Connect("user/password@bogus.world") > ... except DCOracle.error: > ... print "caught" > ... > Traceback (innermost last): > File "", line 2, in ? > File "/opt/oracle/local/lib/python1.5/DCOracle/ocidb.py", line 76, in __init__ > sc=oci_8.Logon(u,p,s) > OracleError: ('ORA-12154: TNS:could not resolve service name\012', 12154) > >>> try: > ... db = DCOracle.Connect("user/password@bogus.world") > ... except DCOracle.error, e: > ... print "caught", e > ... > Traceback (innermost last): > File "", line 2, in ? > File "/opt/oracle/local/lib/python1.5/DCOracle/ocidb.py", line 76, in __init__ > sc=oci_8.Logon(u,p,s) > OracleError: ('ORA-12154: TNS:could not resolve service name\012', 12154) > >>> print e > Traceback (innermost last): > File "", line 1, in ? > NameError: e > >>> try: > ... db = DCOracle.Connect("user/password@bogus.world") > ... except: > ... print "Gotcha Suckers!" > ... > Gotcha Suckers! > >>> print DCOracle.error > oci.error > >>> print DCOracle.error > 'oci.error' > >>> DCOracle.error > 'oci.error' > >>> ^D Looks like DCOracle still uses strings as error objects - bad thing since these are deprecated. This should print the definition location of the error message, BTW: >>> import sys >>> try: ... 1/0 ... except: ... print sys.exc_info() ... (, , ) >>> >>> import exceptions >>> exceptions.ZeroDivisionError sys.exc_info()[0] has the class object you want ! -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Mike.Olson@fourthought.com Fri Aug 4 00:34:15 2000 From: Mike.Olson@fourthought.com (Mike Olson) Date: Thu, 03 Aug 2000 17:34:15 -0600 Subject: [DB-SIG] DCOracle-1.3.0 try/except References: <200008032149.e73LnQD26884@LDL.HealthPartners.COM> <3989F15D.648837F9@lemburg.com> Message-ID: <398A0177.A0D1D9C@FourThought.com> "M.-A. Lemburg" wrote: > > > Looks like DCOracle still uses strings as error objects - bad > thing since these are deprecated. > > This should print the definition location of the error > message, BTW: > > >>> import sys > >>> try: > ... 1/0 > ... except: > ... print sys.exc_info() > ... > (, , ) > >>> > >>> import exceptions > >>> exceptions.ZeroDivisionError > > > sys.exc_info()[0] has the class object you want ! They do use strings, I actually ran into this a bit ago as well. I had to put: except oci.error, e: to get it to work. Mike > > -- > Marc-Andre Lemburg > ______________________________________________________________________ > Business: http://www.lemburg.com/ > Python Pages: http://www.lemburg.com/python/ > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig -- Mike Olson Principal Consultant mike.olson@fourthought.com (303)583-9900 x 102 Fourthought, Inc. http://Fourthought.com Software-engineering, knowledge-management, XML, CORBA, Linux, Python From ldl@LDL.HealthPartners.COM Sun Aug 6 05:59:13 2000 From: ldl@LDL.HealthPartners.COM (LD Landis) Date: Sat, 5 Aug 2000 23:59:13 -0500 (CDT) Subject: [DB-SIG] DCOracle exceptions and 'Connect' vs 'connect' In-Reply-To: <20000804160119.CD2091CF89@dinsdale.python.org> from "db-sig-request@python.org" at Aug 04, 2000 12:01:19 PM Message-ID: <200008060459.e764xEx01494@LDL.HealthPartners.COM> Hi, I was just wondering about the schedule of Digital Creations updating the exception handling of the DCOracle module to use objects rather than strings. Also, the 2.0 spec calls for the service 'connect', and the DCOracle implementation uses 'Connect' instead... these are somewhat minor items, but (IMO) they put some small 'flys in the ointment' (making otherwise fairly generic code rather dependent on the database you are binding to (I'm getting ready to have multiple databases in some cases). Thanks, --ldl From petrilli@amber.org Sun Aug 6 14:19:01 2000 From: petrilli@amber.org (Christopher Petrilli) Date: Sun, 6 Aug 2000 09:19:01 -0400 Subject: [DB-SIG] DCOracle exceptions and 'Connect' vs 'connect' In-Reply-To: <200008060459.e764xEx01494@LDL.HealthPartners.COM>; from ldl@LDL.HealthPartners.COM on Sat, Aug 05, 2000 at 11:59:13PM -0500 References: <20000804160119.CD2091CF89@dinsdale.python.org> <200008060459.e764xEx01494@LDL.HealthPartners.COM> Message-ID: <20000806091901.A6652@trump.amber.org> LD Landis [ldl@LDL.HealthPartners.COM] wrote: > I was just wondering about the schedule of Digital Creations > updating the exception handling of the DCOracle module to use > objects rather than strings. Also, the 2.0 spec calls for the > service 'connect', and the DCOracle implementation uses 'Connect' > instead... these are somewhat minor items, but (IMO) they put > some small 'flys in the ointment' (making otherwise fairly > generic code rather dependent on the database you are binding > to (I'm getting ready to have multiple databases in some cases). Well, there are two issues: 1) Nothing is preventing someone else from doing the work, and submitting patches, or even distributing it themselves. This is the wonder of Open Source. 2) We are working on a full replacement for DCOracle that is OCI8 only (given some serious problems with 8i and beyond), however it is being done in our spare time, not as a funded project, and therefore has no fixed schedule. We are, after all, a commercial company. I hope this helps. Changing those two things in existing code shouldn't be that difficult, honestly, and should be doable by a competent programmer in a day. If you happen to change them, please let us know, we'd love ot integrate the changes. Chris -- | Christopher Petrilli | petrilli@amber.org From ldl@LDL.HealthPartners.COM Mon Aug 7 03:48:46 2000 From: ldl@LDL.HealthPartners.COM (LD Landis) Date: Sun, 6 Aug 2000 21:48:46 -0500 (CDT) Subject: [DB-SIG] DCOracle direction/expectation In-Reply-To: <20000806160151.7E9801CF64@dinsdale.python.org> from "db-sig-request@python.org" at Aug 06, 2000 12:01:51 PM Message-ID: <200008070248.e772mlP04533@LDL.HealthPartners.COM> Christopher, Re: Short term DCOracle I'll likely do it... was reluctant because of not knowing what DC was going to do, and there is DCOracle-1.3.1 (beta), which indicated to me that there was something in the works. I'm not planning to go crazy or anything... but I can justify the time to do it... What is your recommendation? Start with the 1.3.1 stuff? Let me know how to plug-in to your process. Re: Medium term DCOracle I guess that it sounds to me like we should consider DCOracle as beginning to enter its "sunset" years? Therefore, don't invest too much, instead direct efforts at OCI8 (is that the new package name?) I do know that there's quite a bit of new stuff in 8.1, and I'm just beginning to move stuff to 8.1.6 (on AIX, and maybe some 8.0.6) from HP-UX, Tru64, OpenVMS and "Microsoft Windows NT" (complete rehosting, Yey!) Is there any documented list of the the "serious issues" and what the "8i and beyond" means, from your perspective. Re: Helping OCI8 and DB2 I'm not sure just exactly how "forever long" we'll be doing Oracle, but I'd be very happy to help you (and again can justify the time) with your new OCI8 effort. On my "justifable" radar screen is also IBM's UDB/DB2. Sure not interested in doing obviated or duplicate work (an that's the other "wonder of open source"... e.g. not being limited to "internal" secrets held by another, thereby we can work together for the good of ourselves and others). > LD Landis [ldl@LDL.HealthPartners.COM] wrote: > > I was just wondering about the schedule of Digital Creations > > updating the exception handling of the DCOracle module to use > > objects rather than strings.... > > Well, there are two issues: > > 1) Nothing is preventing someone else from doing the work, and > submitting patches, or even distributing it themselves. This is the > wonder of Open Source. > > 2) We are working on a full replacement for DCOracle that is OCI8 only > (given some serious problems with 8i and beyond), however it is being > done in our spare time, not as a funded project, and therefore has no > fixed schedule. We are, after all, a commercial company. > > I hope this helps. Changing those two things in existing code > shouldn't be that difficult, honestly, and should be doable by a > competent programmer in a day. If you happen to change them, please > let us know, we'd love ot integrate the changes. > > Chris > -- > | Christopher Petrilli > | petrilli@amber.org > From mal@lemburg.com Mon Aug 7 10:19:40 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 07 Aug 2000 11:19:40 +0200 Subject: [DB-SIG] DCOracle direction/expectation References: <200008070248.e772mlP04533@LDL.HealthPartners.COM> Message-ID: <398E7F2C.175F14D@lemburg.com> LD Landis wrote: > Re: Helping OCI8 and DB2 > > I'm not sure just exactly how "forever long" we'll be doing Oracle, > but I'd be very happy to help you (and again can justify the time) > with your new OCI8 effort. On my "justifable" radar screen is also > IBM's UDB/DB2. > > Sure not interested in doing obviated or duplicate work (an that's > the other "wonder of open source"... e.g. not being limited to "internal" > secrets held by another, thereby we can work together for the good of > ourselves and others). You will be able to use mx.ODBC for IBM's UDB/DB2 -- they use ODBC as one of their native APIs (just as Solid does). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From dieter@sz-sb.de Mon Aug 7 15:15:59 2000 From: dieter@sz-sb.de (Dr. Dieter Maurer) Date: Mon, 7 Aug 2000 16:15:59 +0200 (CEST) Subject: [DB-SIG] ATTENTION: memory corruption in Oracle 8.1.6 client library on Sun Sparc Solaris Message-ID: <14734.48547.239490.275790@dieter.sz-sb.de> We used DCOracle (August 1999) compiled with -DORACLE8 to connect to an Oracle 8.1.6 database on a Sun Sparc Solaris 2.7 machine .... ... and were plagued by a series of mysterious memory corruption problems. The mean time between failures for our Zope system was between 5 to 15 minutes. An analysis with "purify" detected 2 writes after free in any call to OCILogoff. Further analysis revealed that not only heap memory was corrupted but data in the standard C library as well. The problem disappeared after "DCOracle" was compiled without "-DORACLE8". The Oracle 8.1.6 (release 2.0.6.0.0) client library seems to contain a severe memory corruption bug on Sun Sparc Solaris. Dieter From matt@digicool.com Mon Aug 7 15:45:41 2000 From: matt@digicool.com (Matthew T. Kromer) Date: Mon, 07 Aug 2000 10:45:41 -0400 Subject: [DB-SIG] Re: ATTENTION: memory corruption in Oracle 8.1.6 client library on Sun Sparc Solaris In-Reply-To: <14734.48547.239490.275790@dieter.sz-sb.de> Message-ID: on 8/7/00 10:15 AM, Dr. Dieter Maurer at dieter@sz-sb.de wrote: > We used DCOracle (August 1999) compiled with -DORACLE8 to > connect to an Oracle 8.1.6 database on a Sun Sparc Solaris 2.7 > machine .... > > ... and were plagued by a series of mysterious memory corruption > problems. The mean time between failures for our Zope system > was between 5 to 15 minutes. > > An analysis with "purify" detected > 2 writes after free in any call to OCILogoff. > Further analysis revealed that not only heap memory was corrupted > but data in the standard C library as well. > > > The problem disappeared after "DCOracle" was compiled without > "-DORACLE8". > > The Oracle 8.1.6 (release 2.0.6.0.0) client library seems to contain > a severe memory corruption bug on Sun Sparc Solaris. > Dr. Maurer, there is a later DCOracle (1.3.1b1 or thereabouts) that uses a different OCI logon/logoff mechanism that avoids this problem. From adustman@comstar.net Wed Aug 9 23:20:03 2000 From: adustman@comstar.net (Andy Dustman) Date: Wed, 9 Aug 2000 18:20:03 -0400 (EDT) Subject: [DB-SIG] MySQLdb-0.2.2 released Message-ID: I have finally made the final, real release of MySQLdb-0.2.2. See: http://dustman.net/andy/python/MySQLdb/0.2.2 Among other things, there's real transaction support (needs MySQL-3.23.15+), and a CompatMysqldb module which should be a drop-in replacement for MySQLmodule's Mysqldb, for those of you with legacy code. Consider this bit experimental. Some of the _mysql API has changed a bit, which will foul up anything which uses it (i.e. Zope ZMySQLDA). There's probably a bunch of other stuff I don't remember, but shouldn't cause any problems. -- 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 Martin.Kew@vsl.com.au Thu Aug 10 09:43:34 2000 From: Martin.Kew@vsl.com.au (Martin Kew) Date: Thu, 10 Aug 2000 18:13:34 +0930 Subject: [DB-SIG] PostgresSQL DB-API Driver Message-ID: <4.2.0.58.20000810180134.00bcbf00@imaphost> Is there a DB-API driver for PostgresSQL, I know that there is an interface bundled with postgressSQL but I dont think this interface conforms to the spec. PS I am not a member of the SIG so could you send me a direct email, if you do reply. Thanks Martin. From mal@lemburg.com Thu Aug 10 09:58:02 2000 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 10 Aug 2000 10:58:02 +0200 Subject: [DB-SIG] PostgresSQL DB-API Driver References: <4.2.0.58.20000810180134.00bcbf00@imaphost> Message-ID: <39926E9A.F53E8136@lemburg.com> Martin Kew wrote: > > Is there a DB-API driver for PostgresSQL, I know that there is an interface > bundled with postgressSQL but I dont think this interface conforms to the spec. mx.ODBC can be made to link against the Postgresql ODBC driver (and mx.ODBC is a DB API spec compliant interface). The next release of mx.ODBC will include the following setup as subpackage... Put this into Setup... #### ODBC interface for PostgreSQL 6.5.x ODBC driver # # Note: you will have to fix the paths to point to your installation # directories. # -DPostgreSQL \ -DDONT_HAVE_SQLDescribeParam \ -I/usr/local/pgsql/include/iodbc \ /usr/local/pgsql/lib/libpsqlodbc.so # # ...and add this (modulo some editing) to mxODBC.h of that subpackage: #elif defined(PostgreSQL) /* PostgreSQL ODBC driver */ # include "iodbc.h" # include "isql.h" # include "isqlext.h" # define MXODBC_INTERFACENAME "PostgreSQL ODBC" -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From darcy@druid.net Thu Aug 10 13:20:36 2000 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Thu, 10 Aug 2000 08:20:36 -0400 (EDT) Subject: [DB-SIG] PostgresSQL DB-API Driver In-Reply-To: <4.2.0.58.20000810180134.00bcbf00@imaphost> "from Martin Kew at Aug 10, 2000 06:13:34 pm" Message-ID: Thus spake Martin Kew > Is there a DB-API driver for PostgresSQL, I know that there is an interface > bundled with postgressSQL but I dont think this interface conforms to the spec. > > PS I am not a member of the SIG so could you send me a direct email, if you > do reply. The version of PyGreSQL in the PostgreSQL tree is 2.4. The latest version is 3.0. You can also try the beta version which fixes a few minor bugs. See http://www.druid.net/pygresql/ for full details. -- 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 darcy@druid.net Thu Aug 10 14:03:53 2000 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Thu, 10 Aug 2000 09:03:53 -0400 (EDT) Subject: [DB-SIG] PostgresSQL DB-API Driver In-Reply-To: "from D'Arcy J.M. Cain at Aug 10, 2000 08:20:36 am" Message-ID: Thus spake D'Arcy J.M. Cain > Thus spake Martin Kew > > Is there a DB-API driver for PostgresSQL, I know that there is an interface > > The version of PyGreSQL in the PostgreSQL tree is 2.4. The latest version > is 3.0. You can also try the beta version which fixes a few minor bugs. > See http://www.druid.net/pygresql/ for full details. I forgot to mention that 3.0 has a DB-API interface. -- 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 Martin.Kew@vsl.com.au Fri Aug 11 01:17:04 2000 From: Martin.Kew@vsl.com.au (Martin Kew) Date: Fri, 11 Aug 2000 09:47:04 +0930 Subject: [DB-SIG] PostgresSQL DB-API Driver In-Reply-To: <39926E9A.F53E8136@lemburg.com> References: <4.2.0.58.20000810180134.00bcbf00@imaphost> Message-ID: <4.2.0.58.20000811094332.00bdccb0@imaphost> Thanks Marc-Andre, For your interest I had an email from Yury Don to have a look at the PoPy driver (http://www.mixadlive.com), this seems to be DB-API2 compliant. At 10:58 am 10/08/00 +0200, you wrote: >Martin Kew wrote: > > > > Is there a DB-API driver for PostgresSQL, I know that there is an interface > > bundled with postgressSQL but I dont think this interface conforms to > the spec. > >mx.ODBC can be made to link against the Postgresql ODBC driver (and >mx.ODBC is a DB API spec compliant interface). > >The next release of mx.ODBC will include the following >setup as subpackage... > >Put this into Setup... > >#### ODBC interface for PostgreSQL 6.5.x ODBC driver ># ># Note: you will have to fix the paths to point to your installation ># directories. ># > -DPostgreSQL \ > -DDONT_HAVE_SQLDescribeParam \ > -I/usr/local/pgsql/include/iodbc \ > /usr/local/pgsql/lib/libpsqlodbc.so ># ># > >...and add this (modulo some editing) to mxODBC.h of that subpackage: > >#elif defined(PostgreSQL) >/* PostgreSQL ODBC driver */ ># include "iodbc.h" ># include "isql.h" ># include "isqlext.h" ># define MXODBC_INTERFACENAME "PostgreSQL ODBC" > >-- >Marc-Andre Lemburg >______________________________________________________________________ >Business: http://www.lemburg.com/ >Python Pages: http://www.lemburg.com/python/