From pramirez@chasque.apc.org Mon Oct 1 15:22:21 2001 From: pramirez@chasque.apc.org (=?ISO-8859-1?Q?Pablo_Ram=EDrez?=) Date: Mon, 1 Oct 2001 11:22:21 -0300 Subject: [DB-SIG] how to print Message-ID: <3BB851ED.29325.C1DBD@localhost> Hello: I'm doing mi first serious program in python using Tkinter, and the question is: how to redirect the output to the printer (ej. epson) ?, and, if possible do this function (printing) multiplataform ? Thanks Pablo Ram=EDrez Planee sus negocios con =E9xito http://www.prsystem.com/agendacomercial1/ From cjackson@wacoisd.org Tue Oct 2 17:00:44 2001 From: cjackson@wacoisd.org (Chuck Jackson) Date: Tue, 02 Oct 2001 11:00:44 -0500 Subject: [DB-SIG] Informixdb & Python 2.1.1 Message-ID: <3BB9E4AC.6080208@wacoisd.org> I have the following setup: 1) SuSE 7.2 2) Python 2.1.1 (#1, Sep 26 2001, 15:05:29) [GCC 2.95.3 20010315 (SuSE)] on linux2 3) Informixdb 1.3 4) Informix CLI -- recently nabbed from website, no idea what version # I've mucked with "configure", the resultant Make files etc. I still can't get it to build. The main complaint that I get is: make[1]: Entering directory `/usr/local/informixdb-1.3/ext' make[1]: *** No rule to make target `_informixdb.c', needed by `_informixdb.o'. Stop. make[1]: Leaving directory `/usr/local/informixdb-1.3/ext' make: *** [sharedmods] Error 2 Thanks for your help!! Chuck Jackson From paul@boddie.net Wed Oct 3 09:34:30 2001 From: paul@boddie.net (paul@boddie.net) Date: 3 Oct 2001 08:34:30 -0000 Subject: [DB-SIG] Informixdb & Python 2.1.1 Message-ID: <20011003083430.26654.qmail@www1.nameplanet.com> Chuck Jackson wrote: > >I have the following setup: > >1) SuSE 7.2 > >2) Python 2.1.1 (#1, Sep 26 2001, 15:05:29) >[GCC 2.95.3 20010315 (SuSE)] on linux2 > >3) Informixdb 1.3 >4) Informix CLI -- recently nabbed from website, no idea what version # I'm out of my depth here, having never used SuSE or Informix, although it shouldn't make a huge difference in this case, I think. >I've mucked with "configure", the resultant Make files etc. I still >can't get it to build. The main complaint that I get is: > >make[1]: Entering directory `/usr/local/informixdb-1.3/ext' >make[1]: *** No rule to make target `_informixdb.c', needed by >`_informixdb.o'. Stop. >make[1]: Leaving directory `/usr/local/informixdb-1.3/ext' >make: *** [sharedmods] Error 2 First of all, is there a _informixdb.c file? What happens if you type 'make _informixdb.o'? (I would expect the same error again.) Sometimes, it seems to me, one can get this kind of error when the rules in the Makefile aren't quite right. Are you using GNU make? (This can make a difference, but I would think that on SuSE, GNU make is all you have.) It's too hard to diagnose your problem without any experience of the module in question and without the Makefile to hand. One other thing I can think of, however, is that the module is based on a SWIG (or other comparable interfacing system) wrapping and that the pre-built wrappers aren't supplied. If SWIG is in use, there should be some .i files in the distribution. Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su From TKeating@origin.ea.com Wed Oct 3 17:10:18 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Wed, 3 Oct 2001 11:10:18 -0500 Subject: [DB-SIG] Informixdb & Python 2.1.1 Message-ID: <2292DBED5A978A498EABCCE95524499E0281D6D5@osi-postal.osi.ad.ea.com> If you're really using Informix, you should be able to get support from Borland, no? If you're using the supposed open source release, don't. Allegedly there were lots of problems with it. You should probably be using Firebird, which is an open-source project built atop that initial informix drop. http://firebird.sourceforge.net TK > -----Original Message----- > From: paul@boddie.net [mailto:paul@boddie.net] > Sent: Wednesday, October 03, 2001 3:35 AM > To: db-sig@python.org > Subject: [DB-SIG] Informixdb & Python 2.1.1 > > > Chuck Jackson wrote: > > > >I have the following setup: > > > >1) SuSE 7.2 > > > >2) Python 2.1.1 (#1, Sep 26 2001, 15:05:29) > >[GCC 2.95.3 20010315 (SuSE)] on linux2 > > > >3) Informixdb 1.3 > >4) Informix CLI -- recently nabbed from website, no idea > what version # > > I'm out of my depth here, having never used SuSE or Informix, > although it > shouldn't make a huge difference in this case, I think. > > >I've mucked with "configure", the resultant Make files etc. I still > >can't get it to build. The main complaint that I get is: > > > >make[1]: Entering directory `/usr/local/informixdb-1.3/ext' > >make[1]: *** No rule to make target `_informixdb.c', needed by > >`_informixdb.o'. Stop. > >make[1]: Leaving directory `/usr/local/informixdb-1.3/ext' > >make: *** [sharedmods] Error 2 > > First of all, is there a _informixdb.c file? What happens if > you type 'make > _informixdb.o'? (I would expect the same error again.) > Sometimes, it seems to > me, one can get this kind of error when the rules in the > Makefile aren't quite > right. Are you using GNU make? (This can make a difference, > but I would think > that on SuSE, GNU make is all you have.) > > It's too hard to diagnose your problem without any experience > of the module in > question and without the Makefile to hand. One other thing I > can think of, > however, is that the module is based on a SWIG (or other > comparable interfacing > system) wrapping and that the pre-built wrappers aren't > supplied. If SWIG is in > use, there should be some .i files in the distribution. > > Paul > > -- > Get your firstname@lastname email for FREE at http://Nameplanet.com/?su _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From andy@dustman.net Wed Oct 3 22:24:35 2001 From: andy@dustman.net (Andy Dustman) Date: 03 Oct 2001 17:24:35 -0400 Subject: [DB-SIG] Informixdb & Python 2.1.1 In-Reply-To: <2292DBED5A978A498EABCCE95524499E0281D6D5@osi-postal.osi.ad.ea.com> References: <2292DBED5A978A498EABCCE95524499E0281D6D5@osi-postal.osi.ad.ea.com> Message-ID: <1002144275.13486.8.camel@chef.comstar.net> On Wed, 2001-10-03 at 12:10, Keating, Tim wrote: > If you're really using Informix, you should be able to get support from > Borland, no? Borland has never had anything to do with Informix, AFAIK. IBM bought Informix last year. Before that, they were Informix Corp. www.informix.com redirects here: http://www-4.ibm.com/software/data/informix/ -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From chris@onca.catsden.net Wed Oct 3 22:01:15 2001 From: chris@onca.catsden.net (chris@onca.catsden.net) Date: Wed, 3 Oct 2001 14:01:15 -0700 (PDT) Subject: [DB-SIG] Informixdb & Python 2.1.1 In-Reply-To: <1002144275.13486.8.camel@chef.comstar.net> Message-ID: On 3 Oct 2001, Andy Dustman wrote: > On Wed, 2001-10-03 at 12:10, Keating, Tim wrote: > > If you're really using Informix, you should be able to get support from > > Borland, no? > > Borland has never had anything to do with Informix, AFAIK. IBM bought > Informix last year. Before that, they were Informix Corp. > www.informix.com redirects here: > > http://www-4.ibm.com/software/data/informix/ Someone was obviously thinking of 'InterBase' :) ("`-/")_.-'"``-._ Ch'marr, a.k.a. . . `; -._ )-;-,_`) Chris Cogdon (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' FC1.3: FFH3cmA+>++C++D++H++M++P++R++T+++WZ++Sm++ ((,.-' ((,/ fL RLCT acl+++d++e+f+++h++i++++jp-sm++ From TKeating@origin.ea.com Thu Oct 4 00:29:18 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Wed, 3 Oct 2001 18:29:18 -0500 Subject: [DB-SIG] Informixdb & Python 2.1.1 Message-ID: <2292DBED5A978A498EABCCE95524499E0281D6DE@osi-postal.osi.ad.ea.com> Yeah, someone else pointed that out to me. Informix, Interbase, it's all the same thing, right? Too much crack for breakfast this morning, I guess. > -----Original Message----- > From: Andy Dustman [mailto:andy@dustman.net] > Sent: Wednesday, October 03, 2001 4:25 PM > To: db-sig@python.org > Subject: RE: [DB-SIG] Informixdb & Python 2.1.1 > > > On Wed, 2001-10-03 at 12:10, Keating, Tim wrote: > > If you're really using Informix, you should be able to get > support from > > Borland, no? > > Borland has never had anything to do with Informix, AFAIK. IBM bought > Informix last year. Before that, they were Informix Corp. > www.informix.com redirects here: > > http://www-4.ibm.com/software/data/informix/ > > -- > Andy Dustman PGP: 0x930B8AB6 > @ .net http://dustman.net/andy > You can have my keys when you pry them from my dead, cold neurons. > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From Billy G. Allie" --==_Exmh_-1240586236P Content-Type: text/plain; charset=us-ascii Announce: pyPgSQL - Version 1.6 is released. =========================================================================== pyPgSQL v1.6 has been released. It is primarily a bug fix release to ver- sion 1.5.1, but also include some enhancements. NOTE: This release drops support for PostgreSQL 6.5.x and Python 1.5.x. If you are still using those versions, you are badly in need of an upgrade. It is available at http://sourceforge.net/projects/pypgsql. pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. The first module, libpq, exports the PostgreSQL C API to Python. This module is written in C and can be compiled into Python or can be dynamically loaded on demand. The second module, PgSQL, provides the DB-API 2.0 compliant interface and support for various PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This module is written in Python and works with PostgreSQL 7.0 or later and Python 2.0 or later. Note: It is highly recommended that you use PostgreSQL 7.1 or later and Python 2.1 or later. PostgreSQL is a sophisticated Object-Relational DBMS, supporting almost all SQL constructs, including sub-selects, transactions, and user-defined types and functions. It is the most advanced open-source database available any- where More information about PostgreSQL can be found at the PostgreSQL home page at http://www.postgresql.org. Python is an interpreted, interactive, object-oriented programming lang- uage. It combines remarkable power with very clear syntax. It has mod- ules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems (X11, Motif, Tk, Mac, MFC). New builtin modules are easily written in C or C++. Python is also usable as an exten- sion language for applications that need a programmable interface. Python is copyrighted but freely usable and distributable, even for commercial use. More information about Python can be found on the Python home page at http://www.python.org. --------------------------------------------------------------------------- ChangeLog: =========================================================================== Changes since pyPgSQL Version 1.5.1 =================================== The following regression test cases have been added. Each regression test is designed to rigorously test a specific part of pyPgSQL: pgresult.py - Test cases for the libpq.PgResult object. pgversion.py - Test cases for the libpq.PgVersion object. pgconnection.py - Test cases for the libpq.PgConnection object. Changes to PgSQL.py ------------------- * Added support for the PostgreSQL BYTEA type. This will allow binary values to be stored in the database without the use of Large Objects. * [Bug #455514, #464213] Changed how strings are escaped/quoted for use as parameter in queries. Modified code so that array elements are quoted differently from regular attributes. The repr function is no longer used. * Changed code so that libpq notices are only converted to Warning exceptions in certain specific cases. This will prevent Warning exceptions from occuring when tables with serial fields are created, etc. When Python 2.2 is released, it's Warning framework will be used for libpq notices. * Cleaned up the logic in hadleArray(). * Updated the PgSQL.__doc__ string. * [Feature Request #462588] Cursor.close() no longer ends (rollback) the open transaction when the last cursor is closed. * On Connection.close(), reset all the attributes to a sane state (i.e. None or 0, as appropriate). * [Bug #462589] In a fit of optimization, I had introduced a bug that caused comparisons of PgResultSets to anything to fail. This bug has been squashed. * Fixed several cases of references to non-existing globals in PgMoney. * Previously, I was not building up the description attribute if no rows were returned. The description attribute is now built on the first successful select or cursor fetch. Changes to libpqmodule.c ------------------------ * [Bug #455514, #464213] Added a new function to escape/quote strings. This function will escape/quote values used as array elements differently from regular fields. * Added a new functions to escape/un-escape strings used as input/output to/from bytea fields. These function will escape/quote values used as array elements differently from regular fields. * Removed code related to PostgreSQL 6.5.x. We now only support PostgreSQL 7.0 and later. * Changed 'long long' to 'LONG_LONG'. That way there is no assumption of how a 64bit integer is declared. Changes to pgboolean.c ---------------------- * Fix bug in PgBoolean_FromString; also improve and simplify the string stripping in this method. Changes to pgconnection.c ------------------------- * Removed the pgFixEsc() function. It is no longer needed since repr() is not used to escape/quote strings. * Changed code so that a PgConnection object's members are set to None if the finish() method is called. * Corrected bugs found while developing a set of regression tests for pgconnection.c. * Re-ordered the items in PgConnection_members so that the attributes handled directly by PgConnection_getattr are grouped together and commented appropriately. * Removed code related to PostgreSQL 6.5.x. We now only support PostgreSQL 7.0 and later. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgint2object.c ------------------------- * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgint8object.c ------------------------- * Modified code for 64bit (long long) support in the MS Windows environment with MS Visual C++. * Made changes to avoid use of long long constants. This was done to assist in the use of MS Visual C++, which uses something other than LL to specify long long constants. (It's ugly, I know. Thanks MS.) * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pglargeobject.c -------------------------- * Removed an un-used variable. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgnotify.c --------------------- * Clarified an embedded assignment within an if test. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgresult.c --------------------- * Removed code related to PostgreSQL 6.5.x. We now only support PostgreSQL 7.0 and later. * Fixed a gcc reported int format <-> long int argument mis-match. * Added check to make sure that the result was from a DQL (Data Query Language) statement in methods that only make sense for DQL statement results (fname(), etc.). * Methods that take field and/or tuple indices will now raise an exception if those indices are out of range. The previous behavior was to return the error code from the underlying PostgreSQL C-API function. * The fnumber() method will now raise an exception if it is passed a string that is not a valid column name. The previous behavior was to return the error code from the PostgreSQL C-API PQfnumber function. * Correct some incorrect comments. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. * Added a cache (implemented with a Python Dictionary) for OIDs to hold the result of the check to see if the OID is a large object. This should reduce the number queries sent to the database for this purpose. * Add code to not check OIDs whose value is less than or equal to 1700 (PG_NUMERIC). These OIDs are not large objects. Changes to pgversion.c ---------------------- * Removed variables that are no longer needed/referenced. * Fixed code so that coercion generates an exception if the other object could not be converted to a PgVersion object. * Fixed problem where a variable in PgVersion_New() could be used before it was initialized. * Improved detection of erroneous input strings. * Various minor bug fixes and code cleanup. * Made constructed version string more closely mimic the actual format of the PostgreSQL version string. * Having a __dict__ attribute and calling PyMember_Get() in the PyVersion_getattr function causes dir() to do strange things (like list members twice). I've removed the __dict__ attribute and added methods to emulate a mapping object to PgVersion. A PgVersion object will now act like a dictionary, so use version[key] instead of version.__dict__[key]. * Make PgVersion_New safe for arbitrary input strings. * Make the repr method really return the version string. * Initialize a variable (value) in ver_coerce() to quite an erroneous gcc warning message. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | --==_Exmh_-1240586236P Content-Type: application/pgp-signature -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii Announce: pyPgSQL - Version 1.6 is released. =========================================================================== pyPgSQL v1.6 has been released. It is primarily a bug fix release to ver- sion 1.5.1, but also include some enhancements. NOTE: This release drops support for PostgreSQL 6.5.x and Python 1.5.x. If you are still using those versions, you are badly in need of an upgrade. It is available at http://sourceforge.net/projects/pypgsql. pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. The first module, libpq, exports the PostgreSQL C API to Python. This module is written in C and can be compiled into Python or can be dynamically loaded on demand. The second module, PgSQL, provides the DB-API 2.0 compliant interface and support for various PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This module is written in Python and works with PostgreSQL 7.0 or later and Python 2.0 or later. Note: It is highly recommended that you use PostgreSQL 7.1 or later and Python 2.1 or later. PostgreSQL is a sophisticated Object-Relational DBMS, supporting almost all SQL constructs, including sub-selects, transactions, and user-defined types and functions. It is the most advanced open-source database available any- where More information about PostgreSQL can be found at the PostgreSQL home page at http://www.postgresql.org. Python is an interpreted, interactive, object-oriented programming lang- uage. It combines remarkable power with very clear syntax. It has mod- ules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems (X11, Motif, Tk, Mac, MFC). New builtin modules are easily written in C or C++. Python is also usable as an exten- sion language for applications that need a programmable interface. Python is copyrighted but freely usable and distributable, even for commercial use. More information about Python can be found on the Python home page at http://www.python.org. - --------------------------------------------------------------------------- ChangeLog: =========================================================================== Changes since pyPgSQL Version 1.5.1 =================================== The following regression test cases have been added. Each regression test is designed to rigorously test a specific part of pyPgSQL: pgresult.py - Test cases for the libpq.PgResult object. pgversion.py - Test cases for the libpq.PgVersion object. pgconnection.py - Test cases for the libpq.PgConnection object. Changes to PgSQL.py - ------------------- * Added support for the PostgreSQL BYTEA type. This will allow binary values to be stored in the database without the use of Large Objects. * [Bug #455514, #464213] Changed how strings are escaped/quoted for use as parameter in queries. Modified code so that array elements are quoted differently from regular attributes. The repr function is no longer used. * Changed code so that libpq notices are only converted to Warning exceptions in certain specific cases. This will prevent Warning exceptions from occuring when tables with serial fields are created, etc. When Python 2.2 is released, it's Warning framework will be used for libpq notices. * Cleaned up the logic in hadleArray(). * Updated the PgSQL.__doc__ string. * [Feature Request #462588] Cursor.close() no longer ends (rollback) the open transaction when the last cursor is closed. * On Connection.close(), reset all the attributes to a sane state (i.e. None or 0, as appropriate). * [Bug #462589] In a fit of optimization, I had introduced a bug that caused comparisons of PgResultSets to anything to fail. This bug has been squashed. * Fixed several cases of references to non-existing globals in PgMoney. * Previously, I was not building up the description attribute if no rows were returned. The description attribute is now built on the first successful select or cursor fetch. Changes to libpqmodule.c - ------------------------ * [Bug #455514, #464213] Added a new function to escape/quote strings. This function will escape/quote values used as array elements differently from regular fields. * Added a new functions to escape/un-escape strings used as input/output to/from bytea fields. These function will escape/quote values used as array elements differently from regular fields. * Removed code related to PostgreSQL 6.5.x. We now only support PostgreSQL 7.0 and later. * Changed 'long long' to 'LONG_LONG'. That way there is no assumption of how a 64bit integer is declared. Changes to pgboolean.c - ---------------------- * Fix bug in PgBoolean_FromString; also improve and simplify the string stripping in this method. Changes to pgconnection.c - ------------------------- * Removed the pgFixEsc() function. It is no longer needed since repr() is not used to escape/quote strings. * Changed code so that a PgConnection object's members are set to None if the finish() method is called. * Corrected bugs found while developing a set of regression tests for pgconnection.c. * Re-ordered the items in PgConnection_members so that the attributes handled directly by PgConnection_getattr are grouped together and commented appropriately. * Removed code related to PostgreSQL 6.5.x. We now only support PostgreSQL 7.0 and later. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgint2object.c - ------------------------- * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgint8object.c - ------------------------- * Modified code for 64bit (long long) support in the MS Windows environment with MS Visual C++. * Made changes to avoid use of long long constants. This was done to assist in the use of MS Visual C++, which uses something other than LL to specify long long constants. (It's ugly, I know. Thanks MS.) * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pglargeobject.c - -------------------------- * Removed an un-used variable. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgnotify.c - --------------------- * Clarified an embedded assignment within an if test. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. Changes to pgresult.c - --------------------- * Removed code related to PostgreSQL 6.5.x. We now only support PostgreSQL 7.0 and later. * Fixed a gcc reported int format <-> long int argument mis-match. * Added check to make sure that the result was from a DQL (Data Query Language) statement in methods that only make sense for DQL statement results (fname(), etc.). * Methods that take field and/or tuple indices will now raise an exception if those indices are out of range. The previous behavior was to return the error code from the underlying PostgreSQL C-API function. * The fnumber() method will now raise an exception if it is passed a string that is not a valid column name. The previous behavior was to return the error code from the PostgreSQL C-API PQfnumber function. * Correct some incorrect comments. * Use PyObject_Del() instead of PyMem_Free() in dealloc() to delete the object. * Added a cache (implemented with a Python Dictionary) for OIDs to hold the result of the check to see if the OID is a large object. This should reduce the number queries sent to the database for this purpose. * Add code to not check OIDs whose value is less than or equal to 1700 (PG_NUMERIC). These OIDs are not large objects. Changes to pgversion.c - ---------------------- * Removed variables that are no longer needed/referenced. * Fixed code so that coercion generates an exception if the other object could not be converted to a PgVersion object. * Fixed problem where a variable in PgVersion_New() could be used before it was initialized. * Improved detection of erroneous input strings. * Various minor bug fixes and code cleanup. * Made constructed version string more closely mimic the actual format of the PostgreSQL version string. * Having a __dict__ attribute and calling PyMember_Get() in the PyVersion_getattr function causes dir() to do strange things (like list members twice). I've removed the __dict__ attribute and added methods to emulate a mapping object to PgVersion. A PgVersion object will now act like a dictionary, so use version[key] instead of version.__dict__[key]. * Make PgVersion_New safe for arbitrary input strings. * Make the repr method really return the version string. * Initialize a variable (value) in ver_coerce() to quite an erroneous gcc warning message. - -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | MSN.......: B_G_Allie@email.msn.com |-/-|----- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540 | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (UnixWare) Comment: Exmh version 2.2 06/23/2000 iD8DBQE7u/BjnmIkMXoVVdURAmQ+AJ9lJT/EJqd4hwZKuqfT/0fa7rU3LQCfSVxL GMehlBoePJISuciGkL863lQ= =urYE -----END PGP SIGNATURE----- --==_Exmh_-1240586236P-- From dario@ita.chalmers.se Fri Oct 5 13:12:04 2001 From: dario@ita.chalmers.se (=?iso-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Fri, 5 Oct 2001 14:12:04 +0200 Subject: [DB-SIG] Current status of Gadfly References: <3BAA73BD.5090109@crosswinds.net> Message-ID: <00c401c14d96$f278a2f0$33de1081@ita.chalmers.se> > > > > If you get a recent Zope, it has a patched Gadfly with no warnings. > > > > > Thanks for that, although downloading a full blown content management > system just to get a lightweight database does seem to be a little > excessive to me ;-) > > I'll email Aaron Watters anyway and see what he has to say, if it's > possible to patch the Gadfly sources he releases it may be a worthwhile > exercise. > Hi! I am also interested in the future of Gadfly. If you receive any reply fr= om AW, could you post a summary to the list? In the meantime, I think we can count on Zope keeping at least parts of Gadfly up to date; I belive that it uses the kwParsing stuff internally. Sincerely, /dario - -------------------------------------------------------------------- Dario Lopez-K=E4sten Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services From magnus@thinkware.se Fri Oct 5 14:08:32 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Fri, 05 Oct 2001 15:08:32 +0200 Subject: [DB-SIG] Current status of Gadfly In-Reply-To: <00c401c14d96$f278a2f0$33de1081@ita.chalmers.se> References: <3BAA73BD.5090109@crosswinds.net> Message-ID: <5.1.0.14.0.20011005142216.00b76e88@pop3.norton.antivirus> At 14:12 2001-10-05 +0200, Dario Lopez-K=E4sten wrote: >In the meantime, I think we can count on Zope keeping at least parts of >Gadfly up to date; I belive that it uses the kwParsing stuff internally. But just as with ZODB, a reusable piece of software really needs to be delivered as a separate component. There are certainly many uses for both ZODB and GadFly outside Zope, so it would be very nice if Zope Corp could make them available as separate packages. I guess it works with ZODB through A.M. Kuchling's efforts, but it would be a good thing if they where made accessable as separate packages at the source... I guess Aaron is busy at ReportLab, but if Zope Corp has taken over GadFly kwParsing etc, it would be much better if the page at http://www.chordate.com/gadfly.html (which seems to have been dead for three years--the forum is drowning in spam) was replaced with a link to some suitable place at Zope.org. If it is considered to much work to keep track of two more deliverables, it would certainly be a point to at least provide proper instructions on how to get these databases out of Zope. But if Zope Corp is to be the leader in the Python Community, I think they should make them into proper packages using distutil. Considering that Python as a language is so easy to learn, it's a bit sad that there are still so much "hidden knowledge" concerning what modules to use. I think we need a CPAN clone really badly! (And some books. Anyone writing "Database programming with Python"?) IMHO a CPAN work-alike would be worth much more than all the new spiffy features in Python 2.2! But I guess it's less fun... :-( Vault of Parnassus is a Good Thing, but we need something with an official status which is kept properly up to date, and where lost newbies can get proper guidence on what to use. It would be great if there was some kind of indication of project activity and download frequency etc, so that one could for instance make a reasonable choise on what PostgreSQL interface etc to use. -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 http://www.thinkware.se mailto:magnus@thinkware.se From akuchlin@mems-exchange.org Fri Oct 5 14:17:04 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 5 Oct 2001 09:17:04 -0400 Subject: [DB-SIG] Current status of Gadfly In-Reply-To: <5.1.0.14.0.20011005142216.00b76e88@pop3.norton.antivirus>; from magnus@thinkware.se on Fri, Oct 05, 2001 at 03:08:32PM +0200 References: <3BAA73BD.5090109@crosswinds.net> <00c401c14d96$f278a2f0$33de1081@ita.chalmers.se> <5.1.0.14.0.20011005142216.00b76e88@pop3.norton.antivirus> Message-ID: <20011005091704.B32437@ute.mems-exchange.org> On Fri, Oct 05, 2001 at 03:08:32PM +0200, Magnus Lyck? wrote: >IMHO a CPAN work-alike would be worth much more than all the new spiffy >features in Python 2.2! But I guess it's less fun... :-( Vault of Parnassus Suchandra Thapa posted a prototype to the catalog-sig back in September, and so far exactly zero public comments have been made about. While people *talk* a lot about how nice a catalog would be, deep down I think they don't really care. --amk From ana_must@yahoo.de Mon Oct 8 15:37:59 2001 From: ana_must@yahoo.de (=?iso-8859-1?q?Ana=20Must?=) Date: Mon, 8 Oct 2001 16:37:59 +0200 (CEST) Subject: [DB-SIG] newbie question regarding mxODBC Message-ID: <20011008143759.47125.qmail@web20910.mail.yahoo.com> Hello, using mxODBC, I can successfully connect to an Access database and execute queries. I would like to get the list of the existing tables in the database, but I don't know how. When I use the Cursor method tables(), I just get the value -1. any help, please. __________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de From mal@lemburg.com Mon Oct 8 16:54:50 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 08 Oct 2001 17:54:50 +0200 Subject: [DB-SIG] newbie question regarding mxODBC References: <20011008143759.47125.qmail@web20910.mail.yahoo.com> Message-ID: <3BC1CC4A.92A89BDA@lemburg.com> Ana Must wrote: > > Hello, > > using mxODBC, I can successfully connect to an Access > database and execute queries. I would like to get the > list of the existing tables in the database, but I > don't know how. > When I use the Cursor method tables(), I just get > the value -1. .tables() generates a result set which you must fetch from the database using e.g. .fetchall(). The layout of the result set is documented in your ODBC driver manual but should usually be a superset of what is defined in the ODBC standard documentation (see the mxODBC docs for a link to the Microsoft pages on this). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From Theresa_Stadheim@datacard.com Wed Oct 10 21:59:47 2001 From: Theresa_Stadheim@datacard.com (Theresa_Stadheim@datacard.com) Date: Wed, 10 Oct 2001 15:59:47 -0500 Subject: [DB-SIG] primary keys? Message-ID: Hello all, I am creating an Access database, and am having trouble figuring out how I can add a primary key. Could someone please enlighten me? Thanks, Theresa From Paul.Moore@atosorigin.com Thu Oct 11 16:35:33 2001 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Thu, 11 Oct 2001 16:35:33 +0100 Subject: [DB-SIG] Current status of Gadfly Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B066@UKRUX002.rundc.uk.origin-it.com> From: Andrew Kuchling > On Fri, Oct 05, 2001 at 03:08:32PM +0200, Magnus Lyck? > wrote: > > >IMHO a CPAN work-alike would be worth much more than all > >the new spiffy features in Python 2.2! But I guess it's > >less fun... :-( Vault of Parnassus > > Suchandra Thapa posted a prototype to the catalog-sig back > in September, and so far exactly zero public comments have > been made about. While people *talk* a lot about how nice > a catalog would be, deep down I think they don't really > care. You can read that fact two ways. On the one hand, no-one really cares enough to put in a lot of effort polishing and perfecting the proposals that get made. This is a bad thing, sure. But on the other hand, it also means that people are pragmatic - they don't care about *perfecting* the proposal, they just want something practical, that works. I suspect that if Suchandra simply implemented his proposal, and publicised it, and worked at grabbing as many modules as he could and putting them into his catalog, then it would work, and take off. But that requires one person's commitment and time (and web space). The thing that sometimes saddens me about the Python community is how so many good ideas stagnate because there is too much design and not enough implementation. Of course, I don't implement anything, so my comments can't be seen as anything other than heckling from the peanut gallery :-) BTW, if you wish, you may interpret this message as enthusiastic support for Suchandra's prototype. It is. I haven't used it - I don't read the catalog SIG - but I am strongly in favour of anything in this area. Perl's CPAN isn't perfect - heck, in many ways it's dreadful - but people still point to it as a shining example of how to do things. Parnassus isn't ideal, but still loads of people use it. And as a basis for measuring alternatives, it's often quoted (earlier in this thread, we had the comment "Vault of Parnassus is a Good Thing, but we need something with...") Lack of comments doesn't always mean lack of interest - number of users is the only real measure, and proposals don't have users... Sorry - this touched a nerve. Paul. From TKeating@origin.ea.com Thu Oct 11 17:28:46 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Thu, 11 Oct 2001 11:28:46 -0500 Subject: [DB-SIG] Current status of Gadfly Message-ID: <2292DBED5A978A498EABCCE95524499E0281D72C@osi-postal.osi.ad.ea.com> To further muddy the waters: I am a pretty regular Python user, and obviously I participate in one SIG, but I had no idea what the catalog SIG was about, nor would I be inclined to go looking for it. As a result, I never knew such a thing existed. I think what we really need is a python news center (dare I say, something like Slashdot?) where Python USERS can find out about stuff like this. To paraphrase a marketing person I know, if you build it they will NOT come unless you TELL them about it. Sorry to extend the life of this highly off-topic thread, but I also agree that a CPAN-like repository would be very cool and useful. TK > You can read that fact two ways. On the one hand, no-one > really cares enough > to put in a lot of effort polishing and perfecting the > proposals that get > made. This is a bad thing, sure. But on the other hand, it > also means that > people are pragmatic - they don't care about *perfecting* the > proposal, they > just want something practical, that works. I suspect that if Suchandra > simply implemented his proposal, and publicised it, and > worked at grabbing > as many modules as he could and putting them into his > catalog, then it would > work, and take off. But that requires one person's commitment > and time (and > web space). > > The thing that sometimes saddens me about the Python > community is how so > many good ideas stagnate because there is too much design and > not enough > implementation. Of course, I don't implement anything, so my > comments can't > be seen as anything other than heckling from the peanut gallery :-) > > BTW, if you wish, you may interpret this message as > enthusiastic support for > Suchandra's prototype. It is. I haven't used it - I don't > read the catalog > SIG - but I am strongly in favour of anything in this area. > Perl's CPAN > isn't perfect - heck, in many ways it's dreadful - but people > still point to > it as a shining example of how to do things. Parnassus isn't > ideal, but > still loads of people use it. And as a basis for measuring > alternatives, > it's often quoted (earlier in this thread, we had the comment > "Vault of > Parnassus is a Good Thing, but we need something with...") > Lack of comments > doesn't always mean lack of interest - number of users is the > only real > measure, and proposals don't have users... From guido@python.org Thu Oct 11 17:29:47 2001 From: guido@python.org (Guido van Rossum) Date: Thu, 11 Oct 2001 12:29:47 -0400 Subject: [Catalog-sig] RE: [DB-SIG] Current status of Gadfly In-Reply-To: Your message of "Thu, 11 Oct 2001 11:28:46 CDT." <2292DBED5A978A498EABCCE95524499E0281D72C@osi-postal.osi.ad.ea.com> References: <2292DBED5A978A498EABCCE95524499E0281D72C@osi-postal.osi.ad.ea.com> Message-ID: <200110111629.MAA28675@cj20424-a.reston1.va.home.com> > I think what we really need is a python news center (dare I say, > something like Slashdot?) where Python USERS can find out about > stuff like this. It's called comp.lang.python, and is archived at http://www.python.org/pipermail/python-list/ --Guido van Rossum (home page: http://www.python.org/~guido/) From TKeating@origin.ea.com Thu Oct 11 17:38:27 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Thu, 11 Oct 2001 11:38:27 -0500 Subject: [Catalog-sig] RE: [DB-SIG] Current status of Gadfly Message-ID: <2292DBED5A978A498EABCCE95524499E0281D72E@osi-postal.osi.ad.ea.com> OK, fine. Luddite. :) > -----Original Message----- > From: Guido van Rossum [mailto:guido@python.org] > Sent: Thursday, October 11, 2001 11:30 AM > To: Keating, Tim > Cc: 'db-sig@python.org'; 'catalog-sig@python.org' > Subject: Re: [Catalog-sig] RE: [DB-SIG] Current status of Gadfly > > > > I think what we really need is a python news center (dare I say, > > something like Slashdot?) where Python USERS can find out about > > stuff like this. > > It's called comp.lang.python, and is archived at > http://www.python.org/pipermail/python-list/ > > --Guido van Rossum (home page: http://www.python.org/~guido/) > From kjcole@gri.gallaudet.edu Thu Oct 11 18:50:43 2001 From: kjcole@gri.gallaudet.edu (Kevin Cole) Date: Thu, 11 Oct 2001 13:50:43 -0400 (EDT) Subject: [Catalog-sig] RE: [DB-SIG] Current status of Gadfly In-Reply-To: <200110111629.MAA28675@cj20424-a.reston1.va.home.com> Message-ID: Not only that, there's news from the future in the archives (2007-April and 2005-February, no less). ;-) On Thu, 11 Oct 2001, Guido van Rossum wrote: > It's called comp.lang.python, and is archived at > http://www.python.org/pipermail/python-list/ From k_vertigo@yahoo.com Thu Oct 11 19:04:52 2001 From: k_vertigo@yahoo.com (Kapil Thangavelu) Date: Thu, 11 Oct 2001 11:04:52 -0700 (PDT) Subject: [Catalog-sig] RE: [DB-SIG] Current status of Gadfly In-Reply-To: Message-ID: <20011011180452.80139.qmail@web11603.mail.yahoo.com> and even it has a nice browsing/search interface at http://groups.google.com/groups?hl=en&group=comp.lang.python --- Kevin Cole wrote: > Not only that, there's news from the future in the > archives (2007-April > and 2005-February, no less). ;-) > > On Thu, 11 Oct 2001, Guido van Rossum wrote: > > > It's called comp.lang.python, and is archived at > > http://www.python.org/pipermail/python-list/ > > > _______________________________________________ > Catalog-sig mailing list > Catalog-sig@python.org > http://mail.python.org/mailman/listinfo/catalog-sig __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From magnus@thinkware.se Thu Oct 11 21:28:42 2001 From: magnus@thinkware.se (Magnus Lyckå) Date: Thu, 11 Oct 2001 22:28:42 +0200 Subject: [Catalog-sig] RE: [DB-SIG] Current status of Gadfly In-Reply-To: <200110111629.MAA28675@cj20424-a.reston1.va.home.com> References: <2292DBED5A978A498EABCCE95524499E0281D72C@osi-postal.osi.ad.ea.com> Message-ID: <5.1.0.14.0.20011011203148.009fa820@mail.irrblosset.se> Tim Keating wrote: > > I think what we really need is a python news center (dare I say, > > something like Slashdot?) where Python USERS can find out about > > stuff like this. Guido van Rossum replied: >It's called comp.lang.python, and is archived at >http://www.python.org/pipermail/python-list/ Maybe the link (below) that Kapil Thangavelu mentioned should be put at http://www.python.org/News.html for instance. Sometimes deatils like that makes a big difference. http://groups.google.com/groups?hl=en&group=comp.lang.python The search interface certainly makes the news group more useful. News and mailing lists really only well work if you spend time with them each day. The other links on that page are really good resources, and I usually follow them each Thursday (yes, that's today :) from lwn.net which sadly is treatened by ended funding. And if it's impossible to run a really great Linux news center, then maybe a good Python news center is unlikely. I don't think it's the first time this kind of a suggestion pops up, and if several people think something is lacking, then SOMETHING IS lacking, at least for them. With a great language like python, most things are trivial once you know what to do, and with core languages constructs, it's not difficult to find out what to do. But with everything beyond that, database and other interfaces, GUIs, XML etc, there is much more of a Perl-like there's-more-than-one-way-to-do-it choice, and the novice might not even find one of the ways... It would be wonderful indeed if the information available about all the modules that makes Python so useful would be as excellent as Python itself. That's certainly a thing I'll put on my wishing list for Santa. :) /Magnus P.S. For the first time as a consultant I actually got my first client who specifically hired me for my Python skills a few days ago, so maybe Python is really becoming viable as a career merit. (Unfortunately, it's a fairly tiny assignment--but it is fun!) -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From fionn@spamfilter.de Fri Oct 12 00:21:05 2001 From: fionn@spamfilter.de (Fionn Behrens) Date: Fri, 12 Oct 2001 01:21:05 +0200 (CEST) Subject: [DB-SIG] Ann: pSQL.py (manipulation of SQL dbs through python objects) Message-ID: Hi all! Ian Bicking's announcement of SQLbuilder.py on the webware-discuss mailing list a few days ago (very recommandable, btw; it includes a number of great ideas) reminded me of the fact that I have something slightly similiar on disk for quite some time now. I managed to motivate myself to write a readme and prop up a web page for anyone who might be interested. You can find it at: http://rtfm.n3.net/software/psql/ ABSTRACT: * Are you using a (My)SQL database all day in your programming projects and dont want to write SQL statements again and again all over? * Would you like to use an SQL database in your project without needing to know much about SQL? * Interested in making your database access sources a bit more readable and easier to grok for other programmers? If you can answer YES to one of these, pSQL might be of interest to you. WHAT IT DOES: Basically, pSQL wraps all database access and all data you get from your database into some easy-to-handle and easily usable objects that "feel" like standard python data structures. So, if you have a pSQL database object called "myDB" with a table called Address, you can find all people in that table who are living in Oklahoma by issuing a command like: |>>> res = myDB.Address.City["Oklahoma%"] |>>> len(res) |2 To find out the phone numbers of those two, you can use e.g.: |>>> res.column("Phone") |['0405-12345', '0405-67890'] or: |>>> for r in res: |... print "%s: %s"%(r.Name, r.Phone) |John Doe: 0405-12345 |Joe User: 0405-67890 To change one of those numbers in the database: |>>> john = res[0] |>>> john.Phone = '0405-54321' # or: res[0]["Phone"] = '0405-54321' WHAT IT DOES NOT: pSQL currently works with MySQLdb only. This will change in a future version and an abstraction layer will be added which allows the use of any DB 2.0 API compliant SQL module, e.g. for postgres. Visit the web page for more information. Regards, Fionn From andy@dustman.net Fri Oct 12 00:35:13 2001 From: andy@dustman.net (Andy Dustman) Date: 11 Oct 2001 19:35:13 -0400 Subject: [DB-SIG] Ann: pSQL.py (manipulation of SQL dbs through python objects) In-Reply-To: References: Message-ID: <1002843313.4231.4.camel@chef.comstar.net> On Thu, 2001-10-11 at 19:21, Fionn Behrens wrote: > Ian Bicking's announcement of SQLbuilder.py on the webware-discuss mailing > list a few days ago (very recommandable, btw; it includes a number of great > ideas) reminded me of the fact that I have something slightly similiar on disk > for quite some time now. I managed to motivate myself to write a readme and > prop up a web page for anyone who might be interested. > > You can find it at: http://rtfm.n3.net/software/psql/ Also see http://dustman/net/andy/python/SQLDict -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From paul@boddie.net Fri Oct 12 12:40:36 2001 From: paul@boddie.net (paul@boddie.net) Date: 12 Oct 2001 11:40:36 -0000 Subject: [DB-SIG] Current status of Gadfly Message-ID: <20011012114036.31238.qmail@www3.nameplanet.com> "Moore, Paul" wrote: > >You can read that fact two ways. On the one hand, no-one really cares enough >to put in a lot of effort polishing and perfecting the proposals that get >made. This is a bad thing, sure. But on the other hand, it also means that >people are pragmatic - they don't care about *perfecting* the proposal, they >just want something practical, that works. That's why I become even more cynical than I usually am when I see lots of proposals for things on comp.lang.python. It could be the case with some that the author is saying, "Here's a really neat idea! Now I just want someone else to give me the working version." Meanwhile, there are a lot of Python projects out there which actually exist in working form but get far less publicity than "Frivolous Idea #9257 - A Minor Python Syntax Improvement". >I suspect that if Suchandra simply implemented his proposal, and publicised >it, and worked at grabbing as many modules as he could and putting them into >his catalog, then it would work, and take off. But that requires one person's >commitment and time (and web space). And frequently a financial commitment in addition to any that would automatically come from spending one's time and commitment on something. I suppose this is why people look to the (funded) custodians of Python for more progress in this area. >The thing that sometimes saddens me about the Python community is how so >many good ideas stagnate because there is too much design and not enough >implementation. Of course, I don't implement anything, so my comments can't >be seen as anything other than heckling from the peanut gallery :-) But it's fair comment! The standard "you do it if you're so bothered about it" response is fine for those who can deal with the existing situation and have no incentive to do anything about it, but it doesn't necessarily make those who can't deal with the situation (and who may not be up to implementing such a solution either) any more comfortable. >BTW, if you wish, you may interpret this message as enthusiastic support for >Suchandra's prototype. It is. I haven't used it - I don't read the catalog >SIG - but I am strongly in favour of anything in this area. I saw an implementation based on Zope, but it didn't really show me very much. Prototypes don't necessarily convince people that the "final product" is going to be useful, since prototypes aren't always intended to be useful, and people want to see a certain amount of momentum in certain areas before becoming convinced. It's a bit like a "school reunion" site I've been looking at recently; ignoring the dodgier parts of the implementation, if there weren't any people I know registered on there then I wouldn't be impressed, but since there are people I know on there, it suddenly seems a lot more useful and interesting - I subsequently become convinced that it's a "good thing". >Perl's CPAN isn't perfect - heck, in many ways it's dreadful - but people >still point to it as a shining example of how to do things. Parnassus isn't >ideal, but still loads of people use it. And as a basis for measuring >alternatives, it's often quoted (earlier in this thread, we had the >comment "Vault of Parnassus is a Good Thing, but we need something with...") Parnassus has become increasingly useful and it must surely be *the* site to go to if one is looking for an implementation of something in Python. I get the impression, however, that it's regarded by some in a similar way to how the hardcore GNU people regard Linux - nice as a stopgap implemention of their own agenda until the "real thing" comes out. In both cases, the "real thing" hasn't come out yet, and doesn't look as if it will any time soon in either case. >Lack of comments doesn't always mean lack of interest - number of users is the >only real measure, and proposals don't have users... > >Sorry - this touched a nerve. Yes, I expect to get flamed for this too, but I don't care. I don't think anyone should take what either you or I have written as personal criticism, or indeed criticism of any particular group. Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su From bkc@murkworks.com Fri Oct 12 14:38:48 2001 From: bkc@murkworks.com (Brad Clements) Date: Fri, 12 Oct 2001 09:38:48 -0400 Subject: [DB-SIG] Ann: pSQL.py (manipulation of SQL dbs through python objects) In-Reply-To: <1002843313.4231.4.camel@chef.comstar.net> References: Message-ID: <3BC6B976.28833.4B9DCDA@localhost> On 11 Oct 2001 at 19:35, Andy Dustman wrote: > On Thu, 2001-10-11 at 19:21, Fionn Behrens wrote: > > Ian Bicking's announcement of SQLbuilder.py on the webware-discuss > > mailing list a few days ago (very recommandable, btw; it includes a > > number of great ideas) reminded me of the fact that I have something > > slightly similiar on disk for quite some time now. I managed to motivate > > myself to write a readme and prop up a web page for anyone who might be > > interested. > > > > You can find it at: http://rtfm.n3.net/software/psql/ > > Also see http://dustman/net/andy/python/SQLDict I've been using a modified SQLDict in a big project for over a year. It works well for us. 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 Theresa_Stadheim@datacard.com Fri Oct 12 17:59:16 2001 From: Theresa_Stadheim@datacard.com (Theresa_Stadheim@datacard.com) Date: Fri, 12 Oct 2001 11:59:16 -0500 Subject: [DB-SIG] Why does Autoincrement column require a value??? Message-ID: I created some Python code to create a Primary Key in an Access datatabase, setting the AutoIncrement property to True. I thought an AutoIncrement field would increment by itself, but for some reason when I run the script, it complains that my Primary Key field is Null. Anybody know what I can do about this? Here is the error message: Traceback (most recent call last): File "C:\SmartCard\DC9KParser\Parse9k.py", line 347, in ? parse(fileName, configFile, AccessDataOutput.AccessDataOutput()) File "C:\SmartCard\DC9KParser\Parse9k.py", line 328, in parse out.handleCard(recordNumber, fields) File "C:\SmartCard\DC9KParser\AccessDataOutput.py", line 204, in handleCard self.rs.Update() File "", line 2, in Update pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 'Microsoft JET Database Engine', "The field 'Cards.IDWAutoNumber' cannot contain a Null value because the Required property for this field is set to True. Enter a value in this field.", None, 5003000, -2147217887), None) And here is the code that makes the primary key: # new stuff that doesn't work # interpreter keeps insisting I need a value for IDWAutoNumber # I don't know what kind of value it is looking for and/or how to set a value oColumn = win32com.client.Dispatch("ADOX.Column") oKey = win32com.client.Dispatch("ADOX.Key") oColumn.Name = "IDWAutoNumber" oColumn.ParentCatalog = catalog oColumn.Properties("Autoincrement").Value = 1 table.Columns.Append("IDWAutoNumber", adInteger) oKey.Name = "PrimaryKey" oKey.Type = 1 #win32.com.client.constants.adKeyPrimary oKey.RelatedTable = "Cards" oKey.Columns.append("IDWAutoNumber", adInteger) table.Keys.append(oKey) Thanks, Theresa From Keila - Curitiba - Pr" Olá! Veja meu site pessoal no "Tripod.com.br". Basta clicar no endereço abaixo. GARANTO SER SUI-GENERIS - CLIQUE ABAIXO: http://pastorinha.tripod.com.br/seminarista Mais de 61.000 internautas visitaram a PG., existe 7 Álbuns: Se você quiser, por favor, indique minha Home Page, a outros Internautas. Mais detalhes, se comunique, passe um e-mail, que responderei brevemente. Dentro da Home Page, ao lado das fotos, você poderá saber muito mais sobre mim! Obrigada. e-mail: pastorinha@ieg.com.br Beijos:- Keila - Curitiba - Pr - Podes falar comigo, direto dela. Brevemente uma Carta Aberta. http://pastorinha.tripod.com.br/seminarista "Esta mensagem é enviada com a complacência da nova legislação sobre correio eletrônico, Seção 301, Parágrafo (a) (2) (c) Decreto S. 1618, Título Terceiro aprovado pelo "105º Congresso Base das Normativas Internacionais sobre o SPAM". Este E-mail não poderá ser considerado SPAM quando incluir uma forma de ser removido. Para ser removido de futuros correios, simplesmente responda indicando no Assunto: REMOVER" From magnus@thinkware.se Mon Oct 15 12:22:56 2001 From: magnus@thinkware.se (Magnus Lyckå) Date: Mon, 15 Oct 2001 13:22:56 +0200 Subject: [DB-SIG] Object -> RDBMS wrapper? Message-ID: <5.1.0.14.0.20011015131022.00b83d38@mail.irrblosset.se> I'm about to write some code where classes and several many to many associations will map to tables, initially in MySQL. I was wondering if there is some neat OO Python wrapper for classes/associations to the Python DB API 2.0. I'd love any suggestion on how to do this with least possible work and best possible result! :-) I have a few other wheels to invent, so I thought I'd skip this one! ;-) Thanks in advance, Magnus -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From anthony@computronix.com Mon Oct 15 17:58:27 2001 From: anthony@computronix.com (Anthony Tuininga) Date: Mon, 15 Oct 2001 10:58:27 -0600 Subject: [DB-SIG] cx_Oracle 2.3 Message-ID: <3BCB15B3.8060900@computronix.com> I am pleased to announce the release of cx_Oracle version 2.3. The change log is as follows: Changes from 2.2 to 2.3 1) Incremental performance enhancements (dealing with reusing cursors and bind handles) 2) Ensured that arrays of integers with a single float in them are all treated as floats, as suggested by Martin Koch. 3) Fixed code dealing with scale and precision for both defining a numeric variable and for providing the cursor description; this eliminates the problem of an underflow error (OCI-22054) when retrieving data with non-zero scale. As usual, you can download the new release from http://www.computronix.com/utilities Anthony From Sanjay.Jain@ElPaso.com Mon Oct 15 18:37:55 2001 From: Sanjay.Jain@ElPaso.com (Jain, Sanjay) Date: Mon, 15 Oct 2001 12:37:55 -0500 Subject: [DB-SIG] Executing procedures using OLEDB on Win2K question Message-ID: All, This is Sanjay Jain with El Paso Corporation in Birmingham, Alabama. Our department is learning how to use Python, and I am connecting to Oracle databases using OLEDB on Win2k. I have some difficulty, in that I do not know how to execute procedures or use cursors with OLEDB Python on Win2k. I have searched far and wide, yet I cannot find out how to do these things. We like Python very much so far, but these two items limit our use of it here. Can someone please point me in the right direction? Please copy any reply to sanjay.jain@elpaso.com as I do not subscribe to the mailing list yet :) Thanks Regards, Sanjay Jain ElPaso Corporation Contractor, SNG Transportation Business Systems 1900 5th Avenue North Birmingham, AL 35202-2563 205.326.2057(Off), 205.979.7892(Res) ****************************************************************** This email and any files transmitted with it from the ElPaso Corporation are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. ****************************************************************** From Theresa_Stadheim@datacard.com Mon Oct 15 17:49:34 2001 From: Theresa_Stadheim@datacard.com (Theresa_Stadheim@datacard.com) Date: Mon, 15 Oct 2001 11:49:34 -0500 Subject: [DB-SIG] primary key example!! Message-ID: All, I was finally able to figure out the primary key thing if anybody is curious. Here is a code sample: # attempt to attach to the database - if that fails, create a new one # use the file name as the base name for the database self.dbName = os.path.splitext(fileName)[0] dsn = 'Provider=Microsoft.Jet.OLEDB.4.0;' + \ 'Jet OLEDB:Engine Type=5;' + \ 'Data Source=' + self.dbName + '.mdb' # try to create the database catalog = win32com.client.Dispatch('ADOX.Catalog') try: catalog.Create(dsn) catalog.ActiveConnection = dsn except: raise "Can't connect to database table" # create a table with the appropriate field names table = win32com.client.Dispatch('ADOX.Table') self.rs = win32com.client.Dispatch('ADODB.Recordset') table.Name = "Cards" Column = win32com.client.Dispatch("ADOX.Column") Column.Name = "AutoNumber" Column.Type = 3 # adInteger Column.ParentCatalog = catalog Column.Properties('Autoincrement').Value = win32com.client.pywintypes.TRUE table.Columns.Append(Column) Key = win32com.client.Dispatch("ADOX.Key") Key.Name = "PrimaryKey" Key.Type = 1 #win32.com.client.constants.adKeyPrimary Key.RelatedTable = "Cards" Key.Columns.append("AutoNumber") table.Keys.Append(Key) # add other fields using table.Columns.Append() catalog.Tables.Append(table) del table del catalog From TKeating@origin.ea.com Mon Oct 15 19:50:12 2001 From: TKeating@origin.ea.com (Keating, Tim) Date: Mon, 15 Oct 2001 13:50:12 -0500 Subject: [DB-SIG] Executing procedures using OLEDB on Win2K question Message-ID: <2292DBED5A978A498EABCCE95524499E0281D73F@osi-postal.osi.ad.ea.com> It would be helpful if you could supply a little more information. Are you using the DC Oracle adapter, COM/ADO, or something else? TK > -----Original Message----- > From: Jain, Sanjay [mailto:Sanjay.Jain@ElPaso.com] > Sent: Monday, October 15, 2001 12:38 PM > To: 'db-sig@python.org' > Subject: [DB-SIG] Executing procedures using OLEDB on Win2K question > > > All, > > This is Sanjay Jain with El Paso Corporation in > Birmingham, Alabama. > Our department is learning how to use Python, and I am > connecting to Oracle > databases using OLEDB on Win2k. I have some difficulty, in > that I do not > know how to execute procedures or use cursors with OLEDB > Python on Win2k. I > have searched far and wide, yet I cannot find out how to do > these things. From jno@glasnet.ru Tue Oct 16 09:28:53 2001 From: jno@glasnet.ru (Eugene V . Dvurechenski) Date: Tue, 16 Oct 2001 12:28:53 +0400 Subject: [DB-SIG] cx_Oracle 2.3 In-Reply-To: <3BCB15B3.8060900@computronix.com>; from anthony@computronix.com on Mon, Oct 15, 2001 at 10:58:27AM -0600 References: <3BCB15B3.8060900@computronix.com> Message-ID: <20011016122853.A16728@glas.net> On Mon, Oct 15, 2001 at 10:58:27AM -0600, Anthony Tuininga wrote: > > Changes from 2.2 to 2.3 > is there a comparision of cx_ vs DC Oracle modules? -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From jbelllinux@yahoo.com Tue Oct 16 13:22:34 2001 From: jbelllinux@yahoo.com (Bell John) Date: Tue, 16 Oct 2001 05:22:34 -0700 (PDT) Subject: [DB-SIG] PoPy Large Object Query Message-ID: <20011016122234.35208.qmail@web12602.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sorry that this is product specific, but PoPy (and psycopg) no longer have active websites/mailing lists. I'm trying to find out the syntax in PoPy for import/export of large objects. It's important for me to capture the associated OID. John __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From pcm@mixadlive.com Tue Oct 16 13:56:13 2001 From: pcm@mixadlive.com (Paolo Comitini) Date: Tue, 16 Oct 2001 14:56:13 +0200 Subject: [DB-SIG] PoPy Large Object Query In-Reply-To: <20011016122234.35208.qmail@web12602.mail.yahoo.com> References: <20011016122234.35208.qmail@web12602.mail.yahoo.com> Message-ID: <20011016125347.4BD181854F@developers.parella.mixadlive> On Tuesday 16 October 2001 14:22, Bell John wrote: > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > Sorry that this is product specific, but PoPy (and > psycopg) no longer have active websites/mailing lists. The web site for Psycopg is http://www.init.org/Software/psycopg The Psycopg mailing list is very active! Yuo can consult the archives here: http://lists.initd.org/pipermail/psycopg/ You can search also the archives here: http://lists.initd.org/psycopg-mmsearch.html If you search with the keyword 'OID' you can find this results http://lists.initd.org/cgi-bin/htsearch?config=htdig&restrict=&exclude=&method=and&format=builtin-long&sort=score&words=oid If you need more help, write on the mailing list. The authors, Michele and Federico, will be glad to help you. Ciao Paolo PS: Popy it's our old product, now is maintained by other people. Psycopg is the new Product. It' s written from scracth to avoid all the problems of design of Popy. > > John > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Paolo Comitini pcm@initd.org paolo.comitini@mixadlive.com Mixad Live s.r.l. http://www.mixadlive.com tel +39-0125-669020, fax +39-0125-668984 via della Cartiera 2 10010 - Parella (TO) Italy From thierry@nekhem.com Tue Oct 16 14:11:40 2001 From: thierry@nekhem.com (thierry@nekhem.com) Date: Tue, 16 Oct 2001 15:11:40 +0200 Subject: [DB-SIG] PoPy Large Object Query In-Reply-To: <20011016125347.4BD181854F@developers.parella.mixadlive>; from pcm@mixadlive.com on Tue, Oct 16, 2001 at 02:56:13PM +0200 References: <20011016122234.35208.qmail@web12602.mail.yahoo.com> <20011016125347.4BD181854F@developers.parella.mixadlive> Message-ID: <20011016151140.A5187@musashi.mixad> Hi, I apologize but ... On Tue, Oct 16, 2001 at 02:56:13PM +0200, Paolo Comitini wrote: > On Tuesday 16 October 2001 14:22, Bell John wrote: > PS: > Popy it's our old product, now is maintained by other people. > Psycopg is the new Product. > It' s written from scracth to avoid all the problems of design of Popy. PoPy has __NEVER__ been your product, it was developed by Eric and I and fog helped us to package it (thanks fog for your help). your company used it, that's all!!! Psycopg is your product, no doubt, so Paolo, could you *only* respond for your product, and let me respond for mine ? Thierry From fog@mixadlive.com Tue Oct 16 18:22:45 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Tue, 16 Oct 2001 19:22:45 +0200 Subject: [DB-SIG] PoPy Large Object Query In-Reply-To: <20011016122234.35208.qmail@web12602.mail.yahoo.com> References: <20011016122234.35208.qmail@web12602.mail.yahoo.com> Message-ID: <20011016192244.A5773@developers.mixadlive.com> Scavenging the mail folder uncovered Bell John's letter: > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > Sorry that this is product specific, but PoPy (and > psycopg) no longer have active websites/mailing lists. this is false. the psycopg mailing list and websites are up. traffic on the ML is 2-3 messages/day. try http://lists.initd.org/ and go to the archives. > I'm trying to find out the syntax in PoPy for > import/export of large objects. It's important for me > to capture the associated OID. if i remember correctly you can't grab the oid, because popy handle it itself and convert it into the corresponding lob returned as a binary strung. but it is a long time i don't track popy development, so thing may have changed lately. ciao, federico From fog@mixadlive.com Tue Oct 16 18:29:24 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Tue, 16 Oct 2001 19:29:24 +0200 Subject: [DB-SIG] PoPy Large Object Query In-Reply-To: <20011016151140.A5187@musashi.mixad> References: <20011016122234.35208.qmail@web12602.mail.yahoo.com> <20011016125347.4BD181854F@developers.parella.mixadlive> <20011016151140.A5187@musashi.mixad> Message-ID: <20011016192924.B5773@developers.mixadlive.com> hey guys, calm down, please. do you want to win a prize for the first s**t flame on the db-sig mailing list? i hate doing that on a _public_ mailing list, but lets put things in the right perspective: 1/ popy was developed by thierry and eric with some help from michele (design) and me (packaging) 2/ the copyright on popy belongs to thierry and eric (even if they were working for mixadlive during the development) 3/ psycopg *is* popy redesigned and its enginering derives *even* (but not only) from discussions to which thierry and eric partecipated. this is the whole story. now, please, paolo and thierry, stop it. Scavenging the mail folder uncovered thierry@nekhem.com's letter: > Hi, > > I apologize but ... > > On Tue, Oct 16, 2001 at 02:56:13PM +0200, Paolo Comitini wrote: > > On Tuesday 16 October 2001 14:22, Bell John wrote: > > PS: > > Popy it's our old product, now is maintained by other people. > > Psycopg is the new Product. > > It' s written from scracth to avoid all the problems of design of Popy. > > PoPy has __NEVER__ been your product, it was developed by Eric > and I and fog helped us to package it (thanks fog for your help). > your company used it, that's all!!! > > Psycopg is your product, no doubt, so > Paolo, could you *only* respond for your product, and let me respond for mine ? > > Thierry > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From andy@dustman.net Wed Oct 17 04:35:50 2001 From: andy@dustman.net (Andy Dustman) Date: 16 Oct 2001 23:35:50 -0400 Subject: [DB-SIG] [ANNOUNCE] MySQLdb-0.9.1 Message-ID: <1003289750.22524.3.camel@chef.comstar.net> Hot off the presses: http://sourceforge.net/project/shownotes.php?release_id=51760 -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From jwilhelm@outsourcefinancial.com Thu Oct 18 01:19:48 2001 From: jwilhelm@outsourcefinancial.com (Joseph Wilhelm) Date: Wed, 17 Oct 2001 17:19:48 -0700 Subject: [DB-SIG] mxODBC query results as dictionaries Message-ID: <000b01c1576a$995a5af0$a905a8c0@JWILHELM> This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C1572F.ECFB82F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I scanned through the archives of this mailing list, and saw a bit of a discussion about this subject... but I couldn't find a final definitive answer on it. What is the recommended way, if any, to get rows from a an mxODBC cursor as a dictionary, in the form [ "column_name" : "column_date" ] ? --Joseph Wilhelm ------=_NextPart_000_000C_01C1572F.ECFB82F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I = scanned through=20 the archives of this mailing list, and saw a bit of a discussion about = this=20 subject... but I couldn't find a final definitive answer on it. What is = the=20 recommended way, if any, to get rows from a an mxODBC cursor as a=20 dictionary, in the form [ "column_name" : "column_date" ] = ?
 
--Joseph=20 Wilhelm
------=_NextPart_000_000C_01C1572F.ECFB82F0-- From mal@lemburg.com Thu Oct 18 09:03:19 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 18 Oct 2001 10:03:19 +0200 Subject: [DB-SIG] mxODBC query results as dictionaries References: <000b01c1576a$995a5af0$a905a8c0@JWILHELM> Message-ID: <3BCE8CC7.6887087@lemburg.com> > Joseph Wilhelm wrote: > > I scanned through the archives of this mailing list, and saw a bit of > a discussion about this subject... but I couldn't find a final > definitive answer on it. What is the recommended way, if any, to get > rows from a an mxODBC cursor as a dictionary, in the form [ > "column_name" : "column_date" ] ? Here are some links: http://www.lyra.org/greg/python/ (look for dtuple.py) http://rtfm.n3.net/software/psql/ http://dustman/net/andy/python/SQLDict/ Even though mxODBC provides the needed information for dictionary mappings (column names and values), there is the problem of columns which have database generated names, e.g. for DB functions. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Tue Oct 23 16:04:36 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Tue, 23 Oct 2001 17:04:36 +0200 Subject: [DB-SIG] Optional DB API Extensions Message-ID: <3BD58704.AEE57769@lemburg.com> Here's some food for thought... PEP: ??? Title: Optional Database API Extensions Version: $Revision: 1.0 $ Author: mal@lemburg.com (Marc-Andre=82 Lemburg) Status: Draft Type: Standards Track Python-Version: 2.3 Created: 23-Oct-2001 Post-History:=20 Abstract This pre-PEP should provide a discussion basis for an "Optional Extensions" section in the DB API 2.0 standard PEP 249. Feel free to add/change text as required. Problem Even though the DB API 2.0 standard already provides a multitude of APIs, there are some common situations where a database package writer will want to add features which are specific to the database, but which could also be implemented for other databases as well. This pre-PEP will collect these common extensions for subsequent inclusion in the DB API 2.0 standard. Note that all extensions will be marked "optional", meaning that database writers are free to implement them, but are not required to do so in order to have a DB API 2.0 compatible package. Proposed Common Extensions Cursor Attribute .rownumber This read-only attribute should provide the current 0-based index of the cursor in the result set or -1 if the index cannot be determined. The index can be seen as index of the cursor in a sequence (the result set). The next fetch operation will fetch the row indexed by .rownumber. Connection Attributes .Error, .ProgrammingError, etc. All exception classes defined by the DB API standard should be exposed on the Connection objects are attributes (in addition to being available at module scope). These attributes simplify error handling in multi-connection environments. Cursor Attributes .connection This read-only attribute return a reference to the Connection object on which the cursor was created. The attribute simplifies writing polymorph code in multi-connection environments. Cursor Method .scroll(value[,mode=3D'relative']) Scroll the cursor in the result set to a new position according to mode. =20 If mode is 'relative' (default), value is taken as offset to the current position in the result set, if set to 'absolute', value states an absolute target position. An IndexError should be raised in case a scroll operation would leave the result set. In this case, the cursor position is left undefined (ideal would be to not move the cursor at all). Note: This method should use native scrollable cursors, if available , or revert to an emulation for forward-only scrollable cursors. The method may raise NotSupportedErrors to signal that a specific operation is not supported by the database (e.g. backward scrolling). Cursor Attribute .messages This is a Python list object to which the interface appends tuples (exception class, exception value) for all messages which the interfaces receives from the underlying database for this cursor. The list is cleared by all standard cursor methods calls (prior to executing the call) except for the .fetchXXX() calls automatically to avoid excessive memory usage and can also be cleared by executing "del cursor.messages[:]". All error and warning messages generated by the database are placed into this list, so checking the list allows the user to verify correct operation of the method calls. The aim of this attribute is to eliminate the need for a Warning exception which often causes problems (some warnings really only have informational character). Connection Attribute .messages Same as cursor.messages except that the messages in the list are connection oriented. The list is cleared automatically by all standard connection methods calls (prior to executing the call) to avoid excessive memory usage and can also be cleared by executing "del connection.messages[:]". Scope This PEP only affects database modules/packages which adhere to the Python DB API 2.0 standard. Some of these extensions may become manditory features in future DB API standard versions. Copyright This document has been placed in the public domain. =0C Local Variables: mode: indented-text indent-tabs-mode: nil End: --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From fog@debian.org Wed Oct 24 01:08:29 2001 From: fog@debian.org (Federico Di Gregorio) Date: 24 Oct 2001 02:08:29 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD58704.AEE57769@lemburg.com> References: <3BD58704.AEE57769@lemburg.com> Message-ID: <1003882109.1278.6.camel@nenya> first of all, thank you very much for writing "what i wanted to write by i had not the time". here's a little addiction. some (longer) others will come. what about the distinction of Official extensions (if you implement the extension you _should_ implement it the dbapi way) and Unofficial ones? Can we consider the ones in this pep unofficial and the ones that get moved to the dbapi pep official? (s/// any term you like for official/unofficial.) here's my little addition: Cursor Attribute .lastrowid This read-only attribute provides the rowid of the last modified row (most databases return a rowid only when a single INSERT operation is performed.) If the operation does not set a rowid or if the database does not support rowids, this attribute should be set to None. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org God is real. Unless declared integer. -- Anonymous FORTRAN programmer From bzimmer@ziclix.com Wed Oct 24 02:38:51 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Tue, 23 Oct 2001 20:38:51 -0500 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <1003882109.1278.6.camel@nenya> Message-ID: I like the other suggestions and I think the addition of .lastrowid is also extremely useful. brian -----Original Message----- From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf Of Federico Di Gregorio Sent: Tuesday, October 23, 2001 7:08 PM To: DB-SIG @ Python.org Subject: Re: [DB-SIG] Optional DB API Extensions first of all, thank you very much for writing "what i wanted to write by i had not the time". here's a little addiction. some (longer) others will come. what about the distinction of Official extensions (if you implement the extension you _should_ implement it the dbapi way) and Unofficial ones? Can we consider the ones in this pep unofficial and the ones that get moved to the dbapi pep official? (s/// any term you like for official/unofficial.) here's my little addition: Cursor Attribute .lastrowid This read-only attribute provides the rowid of the last modified row (most databases return a rowid only when a single INSERT operation is performed.) If the operation does not set a rowid or if the database does not support rowids, this attribute should be set to None. -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org God is real. Unless declared integer. -- Anonymous FORTRAN programmer _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From mal@lemburg.com Wed Oct 24 08:44:01 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 24 Oct 2001 09:44:01 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> Message-ID: <3BD67141.356D6200@lemburg.com> Federico Di Gregorio wrote: > > first of all, thank you very much for writing "what i wanted to write by > i had not the time". here's a little addiction. some (longer) others > will come. what about the distinction of Official extensions (if you > implement the extension you _should_ implement it the dbapi way) and > Unofficial ones? Can we consider the ones in this pep unofficial and the > ones that get moved to the dbapi pep official? (s/// any term you like > for official/unofficial.) > > here's my little addition: > > Cursor Attribute .lastrowid > > This read-only attribute provides the rowid of the last > modified row (most databases return a rowid only when a single > INSERT operation is performed.) If the operation does not set > a rowid or if the database does not support rowids, this attribute > should be set to None. Looks OK (though I don't know how many DBs actually implement something like this; I know that MySQL does, but are there others ?). One nit: like with all attribute extensions, if the database does not supply the feature the module should not implement the attribute and if it cannot determine the value it should return -1 (this simplifies checking and is more in sync with the other attributes). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From fog@debian.org Wed Oct 24 10:04:29 2001 From: fog@debian.org (Federico Di Gregorio) Date: 24 Oct 2001 11:04:29 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD67141.356D6200@lemburg.com> References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> Message-ID: <1003914270.2600.14.camel@nenya> On Wed, 2001-10-24 at 09:44, M.-A. Lemburg wrote: [snip] > > Cursor Attribute .lastrowid > >=20 > > This read-only attribute provides the rowid of the last > > modified row (most databases return a rowid only when a single > > INSERT operation is performed.) If the operation does not set > > a rowid or if the database does not support rowids, this attri= bute > > should be set to None. >=20 > Looks OK (though I don't know how many DBs actually implement something > like this; I know that MySQL does, but are there others ?).=20 postgresql. > One nit: like with all attribute extensions, if the database=20 > does not supply the feature the module should not implement the attribute > and if it cannot determine the value it should return -1=20 > (this simplifies checking and is more in sync with the other attributes). i don't think it should return a numeric value. -1 _can_ be a valid rowid on some dbs. None is better, imho. i agree on raising NotImplemented if the db does not support rowids. ciao, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Spesso crescere ed andare a vivere da soli =E8 l'unico modo di restare bambini. -- Alice Fontana From magnus@thinkware.se Wed Oct 24 11:36:21 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Wed, 24 Oct 2001 12:36:21 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <1003914270.2600.14.camel@nenya> References: <3BD67141.356D6200@lemburg.com> <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> Message-ID: <5.1.0.14.0.20011024121350.00bb16b8@mail.irrblosset.se> > > and if it cannot determine the value it should return -1 > > (this simplifies checking and is more in sync with the other= attributes). At 11:04 2001-10-24 +0200, Federico Di Gregorio wrote: >i don't think it should return a numeric value. -1 _can_ be a valid >rowid on some dbs. None is better, imho. I also dislike "-1". Using special values of the normal set of return values is a bad idea. I remember the beginning of January 1999. The PBX's at Swedish hospitals didn't work. I couldn't rent a car because the "system" was down and so on. Year =3D 99 must mean ERROR, right? I could well imagine that someone who is used to the Python way of handling lists would assume that -1 meant the last object. I could even imagine that someone will eventually make some kind of wrapper so that the rowids can be used like list indices etc. After all these years I still make mistakes with string.find()... I'm not suggesting that string.find should raise an exception or return None if nothing is found. After all, not finding a character in a string is something normal, hardly exceptional, and both 0 and None are "false", so returning None would be an invitation to bugs. But I still think the "-1" is a wart. Is it a terrible thing to raise an exception here? After all, if I request a value from a module that doesn't know how to supply that, I think that is a candidate for an exception. Or did I misunderstand something? /Magnus -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From mal@lemburg.com Wed Oct 24 11:56:14 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 24 Oct 2001 12:56:14 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> <1003914270.2600.14.camel@nenya> Message-ID: <3BD69E4E.63A93EAD@lemburg.com> Federico Di Gregorio wrote: > > On Wed, 2001-10-24 at 09:44, M.-A. Lemburg wrote: > [snip] > > > Cursor Attribute .lastrowid > > > > > > This read-only attribute provides the rowid of the last > > > modified row (most databases return a rowid only when a single > > > INSERT operation is performed.) If the operation does not set > > > a rowid or if the database does not support rowids, this attribute > > > should be set to None. > > > > Looks OK (though I don't know how many DBs actually implement something > > like this; I know that MySQL does, but are there others ?). > > postgresql. Ah, ok. > > One nit: like with all attribute extensions, if the database > > does not supply the feature the module should not implement the attribute > > and if it cannot determine the value it should return -1 > > (this simplifies checking and is more in sync with the other attributes). > > i don't think it should return a numeric value. -1 _can_ be a valid > rowid on some dbs. None is better, imho. i agree on raising > NotImplemented if the db does not support rowids. Oh, I didn't know that -1 was a valid ROWID (aren't these beast unsigned integers ?). I'll use None then. I also added some more text explaining how to handle these optional extensions. Do you have any other extensions which you'd like to see in the new DB API section ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From j.andrusaitis@konts.lv Wed Oct 24 13:21:49 2001 From: j.andrusaitis@konts.lv (Jekabs Andrushaitis) Date: Wed, 24 Oct 2001 14:21:49 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD69E4E.63A93EAD@lemburg.com> Message-ID: <000d01c15c86$752f4610$262a949f@konts.lv> > Oh, I didn't know that -1 was a valid ROWID (aren't these beast > unsigned integers ?). I'll use None then. AFAIK, in Oracle ROWID are not even integers - they actually consist of several numbers combined together - datafile ID, block ID etc. So I guess None would be best solution for this property if it is not available in underlaying DB engine. Jekabs From fog@debian.org Wed Oct 24 12:34:59 2001 From: fog@debian.org (Federico Di Gregorio) Date: 24 Oct 2001 13:34:59 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD69E4E.63A93EAD@lemburg.com> References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> <1003914270.2600.14.camel@nenya> <3BD69E4E.63A93EAD@lemburg.com> Message-ID: <1003923299.5939.7.camel@nenya> --=-u4H4Vl5CerCN8/K5EGZ4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2001-10-24 at 12:56, M.-A. Lemburg wrote: > I also added some more text explaining how to handle these optional > extensions. nice. =20 > Do you have any other extensions which you'd like to see in the > new DB API section ? yes, quite a lot (currently i am trying to summarize the long discussion about type casts, remember?) that's why i would like to see the extensions subdivided in 2 (3) categories: 1. unofficial (discussed) extensions. i.e., there is no convergence of oppinions, this extension is still being discussed (putting in in a pep is usefull because usually, discussions on a mailing list go nowhere until someone write down the whole stuff) 2. official (approved) extensions. this extension is not part of the dbapi, but if you implement it, is much better if you follow the pep. 3. extension that gets moved to the dbapi pep (and become part of the dbapi, are no extensions anymore :) i am for moving all your extensions plus mine to the official list. ciao, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org All programmers are optimists. -- Frederick P. Brooks, Jr. --=-u4H4Vl5CerCN8/K5EGZ4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvWp2IACgkQvcCgrgZGjevQsQCZAcqMuTg06AvY0nDXniDg8v1+ jB4An3WSSWUudmh6gx59668m3nIPMjIv =nOfA -----END PGP SIGNATURE----- --=-u4H4Vl5CerCN8/K5EGZ4-- From daniel.dittmar@sap.com Wed Oct 24 12:54:02 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Wed, 24 Oct 2001 13:54:02 +0200 Subject: [DB-SIG] Optional DB API Extensions Message-ID: Would it be useful to have a common connection option 'strict'? Setting this option would generate warnings for optional features, even if the driver supports them. Thus hopefully hinting at portability problems. This option would also be used for certain implementation defined behaviour (e.g. BLOB columns could return a string object as the strict/portable behaviour and some kind of stream as the extended/nonportable behaviour). Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Wed Oct 24 12:35:10 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 24 Oct 2001 13:35:10 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <3BD67141.356D6200@lemburg.com> <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> <5.1.0.14.0.20011024121350.00bb16b8@mail.irrblosset.se> Message-ID: <3BD6A76E.13043EB8@lemburg.com> Magnus Lyck=E5 wrote: >=20 > > > and if it cannot determine the value it should return -1 > > > (this simplifies checking and is more in sync with the other attrib= utes). >=20 > At 11:04 2001-10-24 +0200, Federico Di Gregorio wrote: > >i don't think it should return a numeric value. -1 _can_ be a valid > >rowid on some dbs. None is better, imho. >=20 > I also dislike "-1". Using special values of the normal set of > return values is a bad idea.=20 Agreed.=20 I didn't know that -1 was in fact a valid ROWID; changed to None again. > I remember the beginning of January > 1999. The PBX's at Swedish hospitals didn't work. I couldn't > rent a car because the "system" was down and so on. Year =3D 99 > must mean ERROR, right? I could well imagine that someone who > is used to the Python way of handling lists would assume that > -1 meant the last object. I could even imagine that someone > will eventually make some kind of wrapper so that the rowids > can be used like list indices etc. True, but that wrapper can easily include the needed code to handle negative returns of e.g. .rownumber and then map this to some kind of exception. =20 > After all these years I still make mistakes with string.find()... > I'm not suggesting that string.find should raise an exception > or return None if nothing is found. After all, not finding a > character in a string is something normal, hardly exceptional, > and both 0 and None are "false", so returning None would be > an invitation to bugs. But I still think the "-1" is a wart. Not really: -1 is not in the set of valid values since the return value is meant to be an index into a sequence (of=20 characters) and indexes start at 0. > Is it a terrible thing to raise an exception here? After all, > if I request a value from a module that doesn't know how to > supply that, I think that is a candidate for an exception. Or > did I misunderstand something? It's mainly a performance question: raising exceptions is very expensive and should only be done for unexpected behaviour. OTOH, checking for negative results when querying e.g. .rowcount of .rownumber is fast. --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From bzimmer@ziclix.com Wed Oct 24 13:13:29 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Wed, 24 Oct 2001 07:13:29 -0500 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD67141.356D6200@lemburg.com> Message-ID: > > Looks OK (though I don't know how many DBs actually implement something > like this; I know that MySQL does, but are there others ?). > For what it's worth, Informix has a SERIAL datatype which implements this feature. brian From mal@lemburg.com Wed Oct 24 13:29:53 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 24 Oct 2001 14:29:53 +0200 Subject: [DB-SIG] Optional DB API Extensions References: Message-ID: <3BD6B441.E7505B97@lemburg.com> "Dittmar, Daniel" wrote: > > Would it be useful to have a common connection option 'strict'? > > Setting this option would generate warnings for optional features, even if > the driver supports them. Thus hopefully hinting at portability problems. > This option would also be used for certain implementation defined behaviour > (e.g. BLOB columns could return a string object as the strict/portable > behaviour and some kind of stream as the extended/nonportable behaviour). -1. ODBC has gone down that road and the result is a complete mess of mixing APIs levels with behaviour changes etc. pp. I think the better way to handle extensions is having the user explicitly request them, e.g. for the BLOB extension you mention the module could require the user to set a special type converter prior to executing a .fetch() operation. However, 'strict' reminds me of the way error handling is done in codecs and I think that this idea would also nicely apply to the DB API spec (only that this time we should use callables instead of strings). The reasoning here is that I believe it should be possible to request e.g. that all Warnings be raised as excpetions or to have them only be stored in the .messages lists or to completely silence them. This could be done by adding an optional writeable errorhandler attribute to connections and cursors. The handler is then called like so : handler(connection_or_cursor, errorclass, errorvalue) It could then either raise the exception, log it in .messages or ignore the error (e.g. for informational Warnings). How's that ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From magnus@thinkware.se Wed Oct 24 14:41:57 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Wed, 24 Oct 2001 15:41:57 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD6A76E.13043EB8@lemburg.com> References: <3BD67141.356D6200@lemburg.com> <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> <5.1.0.14.0.20011024121350.00bb16b8@mail.irrblosset.se> Message-ID: <5.1.0.14.0.20011024145210.00bb16b8@mail.irrblosset.se> At 13:35 2001-10-24 +0200, M.-A. Lemburg wrote: > > After all these years I still make mistakes with string.find()... > > I'm not suggesting that string.find should raise an exception > > or return None if nothing is found. After all, not finding a > > character in a string is something normal, hardly exceptional, > > and both 0 and None are "false", so returning None would be > > an invitation to bugs. But I still think the "-1" is a wart. > >Not really: -1 is not in the set of valid values since the >return value is meant to be an index into a sequence (of >characters) and indexes start at 0. I know, it's just that after all these years it STILL feels more natural to write if s.find(x): bla bla than if s.find(x) !=3D -1: bla bla just as I do with re match objects and a lot of other objects like strings, dicts and many home made class instances. I understand why it works like it does, and I don't suggest any change there (wrong forum anyway), but I feel more comfortable with the way re match objects work, returning None if there is nothing to find. Most of the time, python works just as my intuition suggests, almost like spoken language, much closer to the way I think than other programming languages, and "if s.find(x) !=3D -1:" is a deviation, even it I usually spot it before I finish the next line of code... I think it's good if we can avoid these invitations to making mistakes. Exceptions are very explicit... > > Is it a terrible thing to raise an exception here? After all, > > if I request a value from a module that doesn't know how to > > supply that, I think that is a candidate for an exception. Or > > did I misunderstand something? > >It's mainly a performance question: raising exceptions is very >expensive and should only be done for unexpected behaviour. >OTOH, checking for negative results when querying e.g. .rowcount of >.rownumber is fast. Or "is None"... On the other hand, there is a risk that people will use "if rowid:" instead of "if rowid is not None:" and get in trouble if the code is 0! If I cared for performance I'd code in C! ;-) I understand your point, but it doesn't really add up to me anyway. If you know beforehand that this particular DB API doesn't support rowids, there is no point in querying for it. If you write "generic code" and don't know beforehand what DB it is, you might expect an integer and recieve an Oracle tuple or whatever it might be... It's not as in the string.find or re.match example, that sometimes you get a result back, and sometimes you won't. In the case here, the result will be the same with every run, regardless of data, as long as you have imported the same DB API. For me, it is unexpected behaviour to ask a module to deliver a service that it is not ever capable of providing. It has some kind of brute-force taste to it. But I'm sure both Marc-Andre and Federico work much more with these modules than I ever will, so I won't push this issue further. Just as a little annoying suggestion: If you do want your generic high performance code inside this big loop, you could instead of --- while biiiig loooop: ret =3D might.work() if ret =3D=3D -1: ret =3D SomeOtherWayOfFindingOut() use(ret) --- do it like this --- itWorks =3D 1 while biiiig loooop: if itWorks: try: ret =3D might.work() except NotImplemented: itWorks =3D 0 ret =3D SomeOtherWayOfFindingOut() else: ret =3D SomeOtherWayOfFindingOut() use(ret) --- You will only get one exception. You don't call might.work() more than one time if it fails. You also get as many ifs in both cases. This should be as fast if might.works() is in order, and faster if it isn't. /Magnus -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From fog@debian.org Wed Oct 24 14:50:10 2001 From: fog@debian.org (Federico Di Gregorio) Date: 24 Oct 2001 15:50:10 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD6B441.E7505B97@lemburg.com> References: <3BD6B441.E7505B97@lemburg.com> Message-ID: <1003931410.5935.24.camel@nenya> --=-DW7VIERHWYlOkU3QGSQ3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2001-10-24 at 14:29, M.-A. Lemburg wrote: > ODBC has gone down that road and the result is a complete mess of > mixing APIs levels with behaviour changes etc. pp. >=20 > I think the better way to handle extensions is having the user > explicitly request them, e.g. for the BLOB extension you mention the > module could require the user to set a special type converter > prior to executing a .fetch() operation. >=20 > However, 'strict' reminds me of the way error handling is done > in codecs and I think that this idea would also nicely apply > to the DB API spec (only that this time we should use callables > instead of strings). >=20 > The reasoning here is that I believe it should be possible > to request e.g. that all Warnings be raised as excpetions=20 > or to have them only be stored in the .messages lists=20 > or to completely silence them. >=20 > This could be done by adding an optional writeable errorhandler > attribute to connections and cursors. The handler is then > called like so : >=20 > handler(connection_or_cursor, errorclass, errorvalue) agreed. and every module should provide 3 default handlers: one to log to messages, one to raise an exception and one that sends all the crap to /dev/null. how to switch between them? or we simply export them and init the module with the .messages populating one? --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Those who do not study Lisp are doomed to reimplement it. Poorly. -- from Karl M. Hegbloom .signature --=-DW7VIERHWYlOkU3QGSQ3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvWxxEACgkQvcCgrgZGjevD7ACePRwvlhSMDTjwxPZVxYC4l3B4 e1IAni3yb065QzJaFhJZrVVVEO9y+hJX =Eulp -----END PGP SIGNATURE----- --=-DW7VIERHWYlOkU3QGSQ3-- From fog@debian.org Wed Oct 24 14:56:47 2001 From: fog@debian.org (Federico Di Gregorio) Date: 24 Oct 2001 15:56:47 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <5.1.0.14.0.20011024145210.00bb16b8@mail.irrblosset.se> References: <3BD67141.356D6200@lemburg.com> <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> <5.1.0.14.0.20011024121350.00bb16b8@mail.irrblosset.se> <5.1.0.14.0.20011024145210.00bb16b8@mail.irrblosset.se> Message-ID: <1003931807.5939.31.camel@nenya> --=-4CRMPXf7UAX0CV8F+VQ8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, 2001-10-24 at 15:41, Magnus Lyck=E5 wrote: > Just as a little annoying suggestion: If you do want your > generic high performance code inside this big loop, you > could instead of >=20 > --- > while biiiig loooop: > ret =3D might.work() > if ret =3D=3D -1: > ret =3D SomeOtherWayOfFindingOut() > use(ret) > --- >=20 > do it like this > --- > itWorks =3D 1 > while biiiig loooop: > if itWorks: > try: > ret =3D might.work() > except NotImplemented: > itWorks =3D 0 > ret =3D SomeOtherWayOfFindingOut() > else: > ret =3D SomeOtherWayOfFindingOut() > use(ret) > --- >=20 > You will only get one exception. You don't call might.work() > more than one time if it fails. You also get as many ifs in > both cases. This should be as fast if might.works() is in > order, and faster if it isn't. exceptions are there for exceptional circumstances (have you ever tried timing ifs and excepts? ifs are at least 30x faster in python [1.5.x, when i did the experiment]). anyway, while talking about coding styles (a little OT, i know) i think it is better to cleany separate the feature-peeking part from the rest of the code. i.e., if might.work() =3D=3D None: feature_x_present =3D 0 else: feature_x_present =3D 1 ... while biiig looop: if feature_x_present: use(might.work()) else: use(SomeOtherWayOfFindingOut()) but all that is personal taste, off curse.=20 have fun, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org A short story: I want you. I love you. I'll miss you. -- Me --=-4CRMPXf7UAX0CV8F+VQ8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvWyJ8ACgkQvcCgrgZGjevPegCeMoOFLeUCdA319NLGt7LCRerr 7ZkAnROC+ED7/BreEHqOy3QYbmCP5OR6 =sntv -----END PGP SIGNATURE----- --=-4CRMPXf7UAX0CV8F+VQ8-- From daniel.dittmar@sap.com Wed Oct 24 15:46:00 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Wed, 24 Oct 2001 16:46:00 +0200 Subject: [DB-SIG] Optional DB API Extensions Message-ID: > "Dittmar, Daniel" wrote: > > > > Would it be useful to have a common connection option 'strict'? > > > > Setting this option would generate warnings for optional > features, even if > > the driver supports them. Thus hopefully hinting at > portability problems. > From: M.-A. Lemburg [mailto:mal@lemburg.com] > The reasoning here is that I believe it should be possible > to request e.g. that all Warnings be raised as excpetions > or to have them only be stored in the .messages lists > or to completely silence them. How does this differ from the warning framework in Python 2.1? I think the important part is that the warning text (or part of the warning text) is defined in the PEP for each optional feature, thus allowing to compare the warnings for Driver A with the features of driver B. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Wed Oct 24 18:19:50 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 24 Oct 2001 19:19:50 +0200 Subject: [DB-SIG] Optional DB API Extensions References: Message-ID: <3BD6F836.2A6B9C3F@lemburg.com> "Dittmar, Daniel" wrote: > > > From: M.-A. Lemburg [mailto:mal@lemburg.com] > > The reasoning here is that I believe it should be possible > > to request e.g. that all Warnings be raised as excpetions > > or to have them only be stored in the .messages lists > > or to completely silence them. > > How does this differ from the warning framework in Python 2.1? The warning framework is meant for source code warnings, not application run-time warnings. I was talking about making the error reporting in DB API modules customizable using (optional) error handlers. > I think the important part is that the warning text (or part of the warning > text) is defined in the PEP for each optional feature, thus allowing to > compare the warnings for Driver A with the features of driver B. Now this is much better: if all you want is some notice whenever an optional feature is used, then the warning framework in Python 2.1 would work just fine for this and yes, defining a standard warning text is certainly a good approach. However, I wouldn't want to make usage of the warning framework manditory for all DB API modules. It would be an optional feature just like all the other extensions I placed on the list. Does that sound reasonable ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jason.leach@jsthrower.com Wed Oct 24 23:18:25 2001 From: jason.leach@jsthrower.com (Jason C. Leach) Date: Wed, 24 Oct 2001 15:18:25 -0700 Subject: [DB-SIG] Sybase mods for Windows Message-ID: <3BD73E31.36AF78FD@jsthrower.com> hi, Does anyone have the Sybase mods for Windows. j. From zen@shangri-la.dropbear.id.au Thu Oct 25 11:52:20 2001 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Thu, 25 Oct 2001 20:52:20 +1000 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD58704.AEE57769@lemburg.com> Message-ID: <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> On Wednesday, October 24, 2001, at 01:04 AM, M.-A. Lemburg wrote: > Title: Optional Database API Extensions I would call this DB API 2.1 to avoid confusion, or if all the methods do end up being optional, simply updating the existing DB API 2.0 PEP. I think it is important that the current specification ends up in a single document, as opposed to being split up into two separate PEP's. I also would like the connection method: quote(object) Returns a SQL quoted version of the given variable as a string, suitable for execution by the database backend. For example: >>> print con.quote(42) 42 >>> print con.quote("Don't do that!") 'Don''t do that!' >>> print con.quote(time.time()) TO_DATE('01-Jan-2001 12:01','DD-MMM-YYYY H24:MI') I'd also add cursor methods for Python 2.2 iterators: next() Return the next row from the currently executing SQL statement. A StopIteration exception is raised when the result set is exhausted. This method will raise a NameError exception if run under versions of Python earlier than Python 2.2. __iter__() Returns self. Another optional method may be a call to have the fetchXXX methods return dictionaries rather than sequences, as this seems to be a common extension and feature request. Is it worth adding the transaction isolation level stuff I outlined in the DB API 3 strawman I put out a month or two ago? There didn't appear to be much interest in these, but I may be wrong. (I will be getting around to replying to the last round of comments on the 3.0 strawman soon, as I have spare time again as of today). Anyway, the proposal seems good from my point of view. Thanks for the effort :-) -- Stuart Bishop http://shangri-la.dropbear.id.au/ From fog@debian.org Thu Oct 25 12:11:10 2001 From: fog@debian.org (Federico Di Gregorio) Date: 25 Oct 2001 13:11:10 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> References: <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> Message-ID: <1004008270.776.26.camel@nenya> --=-I4bbzwkR2pnVBlqKQVtI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2001-10-25 at 12:52, Stuart Bishop wrote: >=20 > On Wednesday, October 24, 2001, at 01:04 AM, M.-A. Lemburg wrote: >=20 > > Title: Optional Database API Extensions >=20 > I would call this DB API 2.1 to avoid confusion, or if all the > methods do end up being optional, simply updating the existing > DB API 2.0 PEP. I think it is important that the current > specification ends up in a single document, as opposed to being > split up into two separate PEP's. i continue to think we need two pep, one for the official dbapi (2.0, 2.1, 3.0, etc.) and one for the =20 > I also would like the connection method: > quote(object) >=20 > Returns a SQL quoted version of the given variable as a > string, suitable for execution by the database backend. > For example: >=20 > >>> print con.quote(42) > 42 > >>> print con.quote("Don't do that!") > 'Don''t do that!' > >>> print con.quote(time.time()) this is, imo, wrong. you can expect quote() to be able to cope with *any* object. lets stick to the dbapi official types: >>> print con.quote(module.TimestampFromTicks(time.time()))=20 TO_DATE('01-Jan-2001 12:01','DD-MMM-YYYY H24:MI') > I'd also add cursor methods for Python 2.2 iterators: >=20 > next() >=20 > Return the next row from the currently executing SQL=20 > statement. > A StopIteration exception is raised when the result set is=20 > exhausted. > This method will raise a NameError exception if run under=20 > versions of > Python earlier than Python 2.2. >=20 >=20 > __iter__() >=20 > Returns self. agreed. > Another optional method may be a call to have the fetchXXX methods return > dictionaries rather than sequences, as this seems to be a common=20 > extension and feature request. but we need dictionaries able to cope with multiple equal keys (some db allow multiple columns with the same name). also, should the keys be compared ci or cs? > Is it worth adding the transaction isolation level stuff I outlined in > the DB API 3 strawman I put out a month or two ago? There didn't appear > to be much interest in these, but I may be wrong. (I will be getting > around to replying to the last round of comments on the 3.0 strawman > soon, as I have spare time again as of today). i am working on this for psycopg. it is somewhat simplier that your proposal, just a way to ask the db for a given isolation level. or are isolation levels defined at the SQL standard level? ciao, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Debian. The best software from the best people [see above] -- brought to you by One Line Spam --=-I4bbzwkR2pnVBlqKQVtI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvX800ACgkQvcCgrgZGjevODwCfSEcVpYKE5evvI6Uu1E7Em7zi NKQAoKMu4VJCBzZZlosh/eauT+Ns0xA8 =3eeK -----END PGP SIGNATURE----- --=-I4bbzwkR2pnVBlqKQVtI-- From bkline@rksystems.com Thu Oct 25 13:23:29 2001 From: bkline@rksystems.com (Bob Kline) Date: Thu, 25 Oct 2001 08:23:29 -0400 (EDT) Subject: [DB-SIG] Re: [ python-Patches-448841 ] Patch for PEP 249 In-Reply-To: Message-ID: On Wed, 8 Aug 2001 noreply@sourceforge.net wrote: > Patches item #448841, was opened at 2001-08-07 10:14 > > Category: Modules > Status: Open > Resolution: None > Priority: 5 > Submitted By: Bob Kline (bkline) > Assigned to: M.-A. Lemburg (lemburg) > Summary: Patch for PEP 249 > > Initial Comment: > This patch is submitted to clarify the usage of the executemany() > method of the Cursor class. .... > > ---------------------------------------------------------------------- > > >Comment By: M.-A. Lemburg (lemburg) > Date: 2001-08-08 00:54 > > Message: > Logged In: YES > user_id=38388 > > Everything's fine Bob :-) > > I'll check in your patch today. Thanks. How long does it take before a patch in SourceForge finds its way to the Python DB-Sig site? Is there anything further I need to do to have the page at http://python.org/topics/database/DatabaseAPI-2.0.html reflect what is in SourceForge? -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From zen@shangri-la.dropbear.id.au Thu Oct 25 13:02:58 2001 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Thu, 25 Oct 2001 22:02:58 +1000 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <1004008270.776.26.camel@nenya> Message-ID: <3B7FCFF6-C940-11D5-B05D-000393031882@shangri-la.dropbear.id.au> On Thursday, October 25, 2001, at 09:11 PM, Federico Di Gregorio wrote: > this is, imo, wrong. you can expect quote() to be able to cope with > *any* object. lets stick to the dbapi official types: > > >>> print con.quote(module.TimestampFromTicks(time.time())) > TO_DATE('01-Jan-2001 12:01','DD-MMM-YYYY H24:MI') Yup. My mistake. int, float, string, date for sure. Possibly others depending on the driver, such as raw. > but we need dictionaries able to cope with multiple equal keys (some db > allow multiple columns with the same name). also, should the keys be > compared ci or cs? I would keep it simple - dictionary keys are as taken from cursor.description, and behavior undefined if your SQL manages to return columns with the same name. I havn't used a DB that actually lets me do this that I know of. > i am working on this for psycopg. it is somewhat simplier that your > proposal, just a way to ask the db for a given isolation level. or are > isolation levels defined at the SQL standard level? The transaction isolation levels are defined by SQL99 (I think - I cheated and used the JDBC docs rather than wade through the official specs. The proposal was pretty much identical to what JDBC offers in fact). What I had proposed was fairly simple when summarised. Methods: con.default_transaction_level con.set_transaction_level(lev) lev is one of: TRANSACTION_NONE TRANSACTION_READ_UNCOMMITTED TRANSACTION_READ_COMMITTED TRANSACTION_REPEATABLE_READ con.set_transaction_level sets the level as requested, or a higher level if it can't. I think most drivers would simply stay in TRANSACTION_READ_UNCOMMITTED mode and raise an exception if an attempt is made to set it higher. Here are the relevant definitions and such if anyone is interested... Transaction Isolation Levels Dirty reads occur when transactions are allowed to see uncommitted changes to the data. In other words, changes made inside a transaction are visible outside the transaction before they are committed. If the changes are rolled back instead of being committed, it is possible for other transactions to have done work based on incorrect, transient data. Nonrepeatable reads occur when: a. Transaction A reads a row b. Transaction B changes the row c. Transaction A reads the same row a second time and gets different results Phantom reads occur hen: a. Transaction A reads all rows that satisfy a WHERE condition b. Transaction B inserts an additional row that satisfies the same condition. c. Transaction A reevaluates the WHERE condition and picks up the additional 'phantom' row. The following symbolic constants are defined to describe the four transaction isolation levels defined by SQL99. Note that they are in numeric order so comparison operators can be safely used to test for restrictivness. Note that these definitions are taken from the JDBC API 3.0 documentation by Sun. TRANSACTION_NONE No transaction isolation is guarenteed. TRANSACTION_READ_UNCOMMITTED Allows transactions to see uncommitted changes to the data. This means that dirty reads, nonrepeatable reads, and phantom reads are possible. TRANSACTION_READ_COMMITTED Means that any changes made inside a transaction are not visible outside the transaction until the transaction is committed. This prevents dirty reads, but nonrepeatable reads and phantom reads are still possible. TRANSACTION_REPEATABLE_READ Disallows dirty reads and nonrepeatable reads. Phantom read are still possible. TRANSACTION_SERIALIZABLE Specifies that dirty reads, nonrepeatable reads, and phantom reads are prevented. -- Stuart Bishop http://shangri-la.dropbear.id.au/ From matt@zope.com Thu Oct 25 13:37:31 2001 From: matt@zope.com (Matthew T. Kromer) Date: Thu, 25 Oct 2001 08:37:31 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> Message-ID: <0F1C4E89-C945-11D5-AFB1-003065488930@zope.com> On Thursday, October 25, 2001, at 06:52 AM, Stuart Bishop wrote: > > > I also would like the connection method: > quote(object) > > Returns a SQL quoted version of the given variable as a > string, suitable for execution by the database backend. > For example: > Since the primary reason you want quoting is generally to handle cases where you can't directly BIND values to your database, I'm of the opinion that this should be heavily leaned against. Instead, use of parameter binding should be highly encouraged. I would be open to having extension methods which helped construct statements using the API's preferred bind specification method, or a mechanism whereby the application can negotiate with the adapter to choose a quoting mechanism. Having said all of that, this makes me lean towards a bilevel (or trilevel) approach where there is a standard module which all adapters subclass, and an optional module to attempt to provide further adapter abstractions (inter-adapter abstractions). However, I'd leave the current API spec largely untouched except for DRIVER level features; APPLICATION level features (including application convenience functions) belong elsewhere. > I'd also add cursor methods for Python 2.2 iterators: > > next() > [...] > __iter__() > Yep, this is simply a good fit for result sets. > > Another optional method may be a call to have the fetchXXX methods > return > dictionaries rather than sequences, as this seems to be a common > extension > and feature request. This is an application convenience issue to me; and comes at a cost of making things run slower. I don't like preempting the application's speed for the programmer's convenience. To give an example, in DCOracle2, the underlying C module might fetch 40,000 records in .7 seconds -- but wrapping these results as python objects bumps that up to 3.5 seconds, and going through the entire fetchmany() layer (which for DCOracle2 involves converting the column-based results to row-based results) bumps the whole thing up to almost 9 seconds. While this example is an instance which I'm sure can be improved upon, I'm strongly opposed to making the situation worse rather than better. > > Is it worth adding the transaction isolation level stuff I outlined in > the DB API 3 strawman I put out a month or two ago? There didn't appear > to be much interest in these, but I may be wrong. (I will be getting > around to replying to the last round of comments on the 3.0 strawman > soon, as I have spare time again as of today). > > I would endorse anything which attempts to expose more features of the underlying RDBMS; e.g. Oracle can do the transaction levels you mentioned, and can also set transaction IDs for doing transaction coordination and distributed two-phase commit. I would again suggest that there be an underlying base class for all adapters which has some discovery methods in it such that an application can query for capabilities rather than catch NotImplementedErrors. Example dbapi.getSupportedFeatures() = { dbapi.NumericBinds, dbapi.StoredProcedures, dbapi.TransactionControl } I also find it important to emphasize that a test suite should go hand-in-hand with any API; this seems to be a source of frustration for many adapter writers to say "Is this compliant?" From fog@debian.org Thu Oct 25 15:04:38 2001 From: fog@debian.org (Federico Di Gregorio) Date: 25 Oct 2001 16:04:38 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3B7FCFF6-C940-11D5-B05D-000393031882@shangri-la.dropbear.id.au> References: <3B7FCFF6-C940-11D5-B05D-000393031882@shangri-la.dropbear.id.au> Message-ID: <1004018679.2824.13.camel@nenya> --=-s1DZ3sM0qif1i3WtoptS Content-Type: multipart/alternative; boundary="=-pTfvDSRIJM2Uhtp+DAC+" --=-pTfvDSRIJM2Uhtp+DAC+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2001-10-25 at 14:02, Stuart Bishop wrote: [snip] > > but we need dictionaries able to cope with multiple equal keys (some db > > allow multiple columns with the same name). also, should the keys be > > compared ci or cs? >=20 > I would keep it simple - dictionary keys are as taken from=20 > cursor.description, > and behavior undefined if your SQL manages to return columns with the=20 > same name.=20 undefined behavior id definitely unportable. :) > I havn't used a DB that actually lets me do this that I know of. hihi (isteric mood). postgresql obviously. sic. > > i am working on this for psycopg. it is somewhat simplier that your > > proposal, just a way to ask the db for a given isolation level. or are > > isolation levels defined at the SQL standard level? >=20 > The transaction isolation levels are defined by SQL99 (I think - I=20 > cheated > and used the JDBC docs rather than wade through the official specs. The > proposal was pretty much identical to what JDBC offers in fact). >=20 > What I had proposed was fairly simple when summarised. > Methods: > con.default_transaction_level > con.set_transaction_level(lev) > lev is one of: > TRANSACTION_NONE > TRANSACTION_READ_UNCOMMITTED > TRANSACTION_READ_COMMITTED > TRANSACTION_REPEATABLE_READ >=20 > con.set_transaction_level sets the level as requested, or a higher=20 ^^^^^ lower? anyway, what's the transaction level as defined in the dbapi specs? i don't think dbapi specifies one for db that support multiple. > Here are the relevant definitions and such if anyone is interested... [snip] > TRANSACTION_SERIALIZABLE >=20 > Specifies that dirty reads, nonrepeatable reads, and phantom > reads are prevented. psycopg uses this one. thank you very much for the explanation. i would like to see this proposal about transaction levels in the dbapi extensions too. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-pTfvDSRIJM2Uhtp+DAC+ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 2001-10-25 at 14:02, Stuart Bishop wrote:
[snip]
> > but we need dictionaries able =
to cope with multiple equal keys (some db
> > allow multiple columns with the same name=
). also, should the keys be
> > compared ci or cs?
> 
> I would keep it simple - dictionary keys are a=
s taken from 
> cursor.description,
> and behavior undefined if your SQL manages to =
return columns with the 
> same name.
undefined behavior id = definitely unportable. :)
> I havn't used a =
DB that actually lets me do this that I know of.
hihi (isteric = mood). postgresql obviously. sic.
> > i a=
m working on this for psycopg. it is somewhat simplier that your
> > proposal, just a way to ask the db for a =
given isolation level. or are
> > isolation levels defined at the SQL stand=
ard level?
> 
> The transaction isolation levels are defined b=
y SQL99 (I think - I 
> cheated
> and used the JDBC docs rather than wade throug=
h the official specs. The
> proposal was pretty much identical to what JDB=
C offers in fact).
> 
> What I had proposed was fairly simple when sum=
marised.
> Methods:
>      con.default_transaction_level
>      con.set_transaction_level(lev)
>      lev is one of:
>          TRANSACTION_NONE
>          TRANSACTION_READ_UNCOMMITTED
>          TRANSACTION_READ_COMMITTED
>          TRANSACTION_REPEATABLE_READ
> 
>      con.set_transact=
ion_level sets the level as requested, or a higher
  = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;  ^^^^^
lower? anyway, what's the transaction level as defined in the dbapi specs? = i don't think dbapi specifies one for db that support multiple.
> Here are the relevant definitions and such if anyone =
is interested...
[snip]
>          TRANSACTION_SERIALIZABLE
> 
>              Specifies that dirty reads, nonre=
peatable reads, and phantom
>              reads are prevented.
psycopg uses t= his one. thank you very much for the explanation. i would like to see this = proposal about transaction levels in the dbapi extensions too.
--=20
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.or=
g
INIT.D Developer                                           fog@initd.org
                           Don't dream it. Be it. -- Dr. Frank'n'further
--=-pTfvDSRIJM2Uhtp+DAC+-- --=-s1DZ3sM0qif1i3WtoptS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvYG/YACgkQvcCgrgZGjesmRgCcCSslkNgHsQQAPjZAVNc48Hqn LZkAnAz/M4GixDPZciUla9HuOR0/TV1X =7IHR -----END PGP SIGNATURE----- --=-s1DZ3sM0qif1i3WtoptS-- From magnus@thinkware.se Thu Oct 25 15:21:16 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Thu, 25 Oct 2001 16:21:16 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <1004008270.776.26.camel@nenya> References: < <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> Message-ID: <5.1.0.14.0.20011025154858.02844a70@mail.irrblosset.se> At 13:11 2001-10-25 +0200, Federico Di Gregorio wrote: >i am working on this for psycopg. it is somewhat simplier that your >proposal, just a way to ask the db for a given isolation level. or are >isolation levels defined at the SQL standard level? They are, but how many RDBMS's adhere to the standard? SQL/92 defines these transaction levels: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ and SERIALIZABLE. I'm not sure all major databases still implement them quite like that though. If I remember correctly, DB2 used other names last time I tried (v 5.2?). Oracle 7 used 3 options for SET TRANSACTION: READ ONLY, READ WRITE and USE ROLEBACK SEGMENT ... But that's not really isolation levels. I don't know about more current Oracle versions. SQL Server 7.0 follows the standard. So does MySQL, which is a bit funny since it doesn't handle transactions at all in the standard version. :-) PostgreSQL only supports READ COMMITTED and SERIALIZABLE, but the manuals warn that SERIALIZABLE isn't quite what it says... -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From andy@dustman.net Thu Oct 25 15:28:19 2001 From: andy@dustman.net (Andy Dustman) Date: 25 Oct 2001 10:28:19 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> References: <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> Message-ID: <1004020099.26785.18.camel@chef.comstar.net> On Thu, 2001-10-25 at 06:52, Stuart Bishop wrote: > I also would like the connection method: > quote(object) > > Returns a SQL quoted version of the given variable as a > string, suitable for execution by the database backend. MySQLdb does this, though the method is connection.literal(object). It looks up the correct conversion function for that type/class in connection.converter (defaulting to str()) and then escapes any special characters. If a non-string sequence is passed, the sequence is preserved and the objects in the sequences are converted. > I'd also add cursor methods for Python 2.2 iterators: > > next() > > Return the next row from the currently executing SQL > statement. > A StopIteration exception is raised when the result set is > exhausted. > This method will raise a NameError exception if run under > versions of > Python earlier than Python 2.2. This can be implemented as: def next(self): row = self.fetchone() if row: return row else: raise StopIteration In fact if you run this on earlier versions of Python, you will get a NameError when the result set is exhausted, unless you've otherwise defined StopIteration. It seems like this (and __iter__()) could be implemented for all Python versions, even pre-2.2 where iterators do not exist (and these methods are unlikely to be used in those versions anyway). > Another optional method may be a call to have the fetchXXX methods return > dictionaries rather than sequences, as this seems to be a common > extension > and feature request. MySQLdb is extended to use user-defined Cursor classes to produce abnormal behavior, such as DictCursor returning dictionaries. As has been pointed out, your query may return two columns of the same name. DictCursor deals with this by using table.column as the key for the second column of the same name. Preferably, queries should *not* return two columns with the same name: One should be renamed with the SQL column AS alias syntax. Another cursor class, OldDictCursor, was defined for compatibility with the old MySQLmodule, and sets all keys to table.column. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From andy@dustman.net Thu Oct 25 15:59:36 2001 From: andy@dustman.net (Andy Dustman) Date: 25 Oct 2001 10:59:36 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD58704.AEE57769@lemburg.com> References: <3BD58704.AEE57769@lemburg.com> Message-ID: <1004021976.26785.37.camel@chef.comstar.net> On Tue, 2001-10-23 at 11:04, M.-A. Lemburg wrote: > Cursor Attribute .rownumber Now implemented in MySQLdb (was cursor._pos). > Connection Attributes .Error, .ProgrammingError, etc. Implemented. > Cursor Attributes .connection Implemented (was cursor.__conn). > Cursor Method .scroll(value[,mode='relative']) Currently I have cursor.seek() and cursor.tell(), which work as the file object methods. > Cursor Attribute .messages > Connection Attribute .messages Not really sold on these yet, particularly the last one. Presently you can turn Warnings off, and look at cursor._info (or connection.info()) for the last message. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From andy@dustman.net Thu Oct 25 16:04:32 2001 From: andy@dustman.net (Andy Dustman) Date: 25 Oct 2001 11:04:32 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <1003882109.1278.6.camel@nenya> References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> Message-ID: <1004022272.27003.42.camel@chef.comstar.net> On Tue, 2001-10-23 at 20:08, Federico Di Gregorio wrote: > Cursor Attribute .lastrowid Implemented in MySQLdb (was cursor._insert_id or cursor.insert_id()). -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From mal@lemburg.com Thu Oct 25 13:54:16 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 25 Oct 2001 14:54:16 +0200 Subject: [DB-SIG] Re: [ python-Patches-448841 ] Patch for PEP 249 References: Message-ID: <3BD80B78.69954479@lemburg.com> Bob Kline wrote: > > On Wed, 8 Aug 2001 noreply@sourceforge.net wrote: > > > Patches item #448841, was opened at 2001-08-07 10:14 > > > > Submitted By: Bob Kline (bkline) > > Assigned to: M.-A. Lemburg (lemburg) > > Summary: Patch for PEP 249 > > > > Initial Comment: > > > This patch is submitted to clarify the usage of the executemany() > > method of the Cursor class. .... > > > > ---------------------------------------------------------------------- > > > > >Comment By: M.-A. Lemburg (lemburg) > > Date: 2001-08-08 00:54 > > > > Message: > > Logged In: YES > > user_id=38388 > > > > Everything's fine Bob :-) > > > > I'll check in your patch today. Thanks. > > How long does it take before a patch in SourceForge finds its way to the > Python DB-Sig site? Is there anything further I need to do to have the > page at http://python.org/topics/database/DatabaseAPI-2.0.html reflect > what is in SourceForge? That page is outdated. The link should really point to the PEP page on SF which should have your patch included. Perhaps the DB SIG maintainer could change the link to point to the PEP ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From bzimmer@ziclix.com Thu Oct 25 18:52:31 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Thu, 25 Oct 2001 12:52:31 -0500 Subject: [DB-SIG] Optional DB API Extensions References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <1004022272.27003.42.camel@chef.comstar.net> Message-ID: <003601c15d7d$d24e0c30$3b380f0a@divine.com> What happens in the case of: cur.execute("insert into x values (?, ?)", [(a, b), (c, d)]) I presume the .lastrowid is the value of the insert with (c, d)? thanks, brian ----- Original Message ----- From: "Andy Dustman" To: "DB-SIG @ Python.org" Sent: Thursday, October 25, 2001 10:04 AM Subject: Re: [DB-SIG] Optional DB API Extensions > On Tue, 2001-10-23 at 20:08, Federico Di Gregorio wrote: > > Cursor Attribute .lastrowid > > Implemented in MySQLdb (was cursor._insert_id or cursor.insert_id()). > > -- > Andy Dustman PGP: 0x930B8AB6 > @ .net http://dustman.net/andy > You can have my keys when you pry them from my dead, cold neurons. > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From andy@dustman.net Thu Oct 25 19:09:33 2001 From: andy@dustman.net (Andy Dustman) Date: 25 Oct 2001 14:09:33 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <003601c15d7d$d24e0c30$3b380f0a@divine.com> References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <1004022272.27003.42.camel@chef.comstar.net> <003601c15d7d$d24e0c30$3b380f0a@divine.com> Message-ID: <1004033373.27003.60.camel@chef.comstar.net> On Thu, 2001-10-25 at 13:52, brian zimmer wrote: > What happens in the case of: > > cur.execute("insert into x values (?, ?)", [(a, b), (c, d)]) > > I presume the .lastrowid is the value of the insert with (c, d)? Actually, with MySQLdb you need: cur.executemany("insert into x values (%s, %s)", [(a, b), (c, d)]) (execute is deprecated by DB-API 2.0 for multi-row inserts) But yes, it's the last row id, i.e. the last one inserted. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From zen@shangri-la.dropbear.id.au Fri Oct 26 06:14:58 2001 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Fri, 26 Oct 2001 15:14:58 +1000 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <0F1C4E89-C945-11D5-AFB1-003065488930@zope.com> Message-ID: <668B25DE-C9D0-11D5-B697-000393031882@shangri-la.dropbear.id.au> On Thursday, October 25, 2001, at 10:37 PM, Matthew T. Kromer wrote: > > On Thursday, October 25, 2001, at 06:52 AM, Stuart Bishop wrote: > >> >> >> I also would like the connection method: >> quote(object) >> >> Returns a SQL quoted version of the given variable as a >> string, suitable for execution by the database backend. >> For example: >> > Since the primary reason you want quoting is generally to handle cases > where you can't directly BIND values to your database, I'm of the > opinion that this should be heavily leaned against. Instead, use of > parameter binding should be highly encouraged. Definitely encouraged, which is is best done with documentation. The two things I do with this sort method (using Perl is a past life, and now Zope) are: - Generate logs of SQL commands sent to the RDBMS. - Generate hairy single use SQL dynamically for data mining type reports. > I would be open to having extension methods which helped construct > statements using the API's preferred bind specification method, or a > mechanism whereby the application can negotiate with the adapter to > choose a quoting mechanism. A different method of getting this functionality would be: sql(command,params) >>> con.sql('SELECT * FROM users WHERE username = :p1',('zen',)) This would be useful for the first case I mentioned, but more obtuse for the second case since I would end up doing ''' con.sql(':p1',('zen',)) ''' to retrieve the quoted parameter. > Having said all of that, this makes me lean towards a bilevel (or > trilevel) approach where there is a standard module which all adapters > subclass, and an optional module to attempt to provide further adapter > abstractions (inter-adapter abstractions). However, I'd leave the > current API spec largely untouched except for DRIVER level features; > APPLICATION level features (including application convenience > functions) belong elsewhere. This is similar to the approach the DB API 3.0 strawman I put out a few months ago was heading for. I think this sort of thing is beyond the scope of Marc-Andre's proposal as it stands (although he may decide to grow it). > This is an application convenience issue to me; and comes at a cost of > making things run slower. I don't like preempting the application's > speed for the programmer's convenience. To give an example, in > DCOracle2, the underlying C module might fetch 40,000 records in .7 > seconds -- but wrapping these results as python objects bumps that up > to 3.5 seconds, and going through the entire fetchmany() layer (which > for DCOracle2 involves converting the column-based results to row-based > results) bumps the whole thing up to almost 9 seconds. While this > example is an instance which I'm sure can be improved upon, I'm > strongly opposed to making the situation worse rather than better. But is it worth having as an optional method? If this behavior is already being exposed by drivers, then its worth having a common invocation just to make things more consistent. The documentation should come with a comment along the lines of "don't use dictionaries if you want your code to run fast". > I would endorse anything which attempts to expose more features of the > underlying RDBMS; e.g. Oracle can do the transaction levels you > mentioned, and can also set transaction IDs for doing transaction > coordination and distributed two-phase commit. What methods would transaction coordination and distributed two-phase commit require? -- Stuart Bishop http://shangri-la.dropbear.id.au/ From zen@shangri-la.dropbear.id.au Fri Oct 26 08:28:31 2001 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Fri, 26 Oct 2001 17:28:31 +1000 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <1004018679.2824.13.camel@nenya> Message-ID: <0E6525D4-C9E3-11D5-B697-000393031882@shangri-la.dropbear.id.au> On Friday, October 26, 2001, at 12:04 AM, Federico Di Gregorio wrote: > undefined behavior id definitely unportable. :) Well, if your database doesn't refuse to process the SQL in the first place, an exception would be thrown if you attempt to coerce the result into a dictionary. Hows that? > >=A0=A0=A0=A0=A0 con.set_transaction_level sets the level as = requested, or a=20 > higher > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^ > lower? anyway, what's the transaction level as defined in the dbapi=20 > specs? i don't think dbapi specifies one for db that support multiple. Higher. Or I guess that this should be 'more protective'. The rationalization for this is that if I need to set a specific=20 transaction isolation level, I want *at least* that amount of protection. As the method would=20= return the actual level set, if you application *does* require a particular=20 level this return code can be checked. dbapi currently doesn't specify any transaction levels - this is left up=20= to the drivers to define and document. > psycopg uses this one. thank you very much for the explanation. i = would=20 > like to see this proposal about transaction levels in the dbapi=20 > extensions too. So psycopg would have the trivial task of implementing this=20 specification as: def set_transaction_level(self,lev): return 4 def get_default_transaction_level(self): return 4 Note that unless a shared python module is being distributed, we need to=20= define the transaction isolation levels as integers as opposed to symbolic=20 constants (thus the 'return 4' above. -- Stuart Bishop http://shangri-la.dropbear.id.au/ From fog@debian.org Fri Oct 26 08:51:54 2001 From: fog@debian.org (Federico Di Gregorio) Date: 26 Oct 2001 09:51:54 +0200 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <003601c15d7d$d24e0c30$3b380f0a@divine.com> References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <1004022272.27003.42.camel@chef.comstar.net> <003601c15d7d$d24e0c30$3b380f0a@divine.com> Message-ID: <1004082714.1169.3.camel@nenya> --=-d6EySIi5FKPOzvlJpHm5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2001-10-25 at 19:52, brian zimmer wrote: > What happens in the case of: >=20 > cur.execute("insert into x values (?, ?)", [(a, b), (c, d)]) >=20 > I presume the .lastrowid is the value of the insert with (c, d)?=20 psycopg does that. what about two attributes? lastrowid - rowid of the last execute lastrowids - a tuple of rowids from the last executemany too complicated? --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org The devil speaks truth much oftener than he's deemed. He has an ignorant audience. -- Byron --=-d6EySIi5FKPOzvlJpHm5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjvZFhoACgkQvcCgrgZGjevbVACgtMuNYqN+mfVVxR+677AnXOjf Nw4An32PA4I28sdJMB9MJDjwjbMjiD4p =X4X+ -----END PGP SIGNATURE----- --=-d6EySIi5FKPOzvlJpHm5-- From matt@zope.com Fri Oct 26 13:23:06 2001 From: matt@zope.com (Matthew T. Kromer) Date: Fri, 26 Oct 2001 08:23:06 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <668B25DE-C9D0-11D5-B697-000393031882@shangri-la.dropbear.id.au> Message-ID: <35AA45DA-CA0C-11D5-8156-003065488930@zope.com> On Friday, October 26, 2001, at 01:14 AM, Stuart Bishop wrote: > > What methods would transaction coordination and distributed two-phase > commit require? I think there's two or three methods involved. One is setTransactionID, of which a variant is setTransactionXID, which is a portable transactionID (or some such -- anyway, there's a portable and non-portable transaction ID format in Oracle, with the portable one being an ANSI standard, I think). The second/third is a database.prepare() mechanism to initiate the prepare phase of the two-phase commit. I don't recall at the moment if the transaction ID is applied to statement handles or connections, but I would presume it's applied to connections. Of course, once you can set a transaction ID, its fairly reasonable to expect the application to wish to query it again, so a get operation (or two) would be required. From mal@lemburg.com Fri Oct 26 13:38:30 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 26 Oct 2001 14:38:30 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <5CF9A916-C936-11D5-B05D-000393031882@shangri-la.dropbear.id.au> Message-ID: <3BD95946.5C4799D6@lemburg.com> Stuart Bishop wrote: > > On Wednesday, October 24, 2001, at 01:04 AM, M.-A. Lemburg wrote: > > > Title: Optional Database API Extensions > > I would call this DB API 2.1 to avoid confusion, or if all the > methods do end up being optional, simply updating the existing > DB API 2.0 PEP. This is what my plans is (to update the DB API 2.0 PEP). > I think it is important that the current > specification ends up in a single document, as opposed to being > split up into two separate PEP's. Right. > I also would like the connection method: > quote(object) > > Returns a SQL quoted version of the given variable as a > string, suitable for execution by the database backend. > For example: > > >>> print con.quote(42) > 42 > >>> print con.quote("Don't do that!") > 'Don''t do that!' > >>> print con.quote(time.time()) > TO_DATE('01-Jan-2001 12:01','DD-MMM-YYYY H24:MI') Hmm, why would you need this ? The database module will apply the needed quoting for you if you use bound parameters (which is strongly encouraged). > I'd also add cursor methods for Python 2.2 iterators: > > next() > > Return the next row from the currently executing SQL > statement. > A StopIteration exception is raised when the result set is > exhausted. > This method will raise a NameError exception if run under > versions of > Python earlier than Python 2.2. > > __iter__() > > Returns self. Good idea. > Another optional method may be a call to have the fetchXXX methods return > dictionaries rather than sequences, as this seems to be a common > extension > and feature request. Bad idea ;-) There are plenty tools out there to turn the tuples into dictionaries. The dictionary approach also has some drawbacks, e.g. what to do about columns which are calculated rather than fetched from a database table. I'd rather leave this to (simple to write) tools which take the standard output and turn it into whatever the application wants/needs (e.g. dictionaries, instances, lists, etc.). > Is it worth adding the transaction isolation level stuff I outlined in > the DB API 3 strawman I put out a month or two ago? There didn't appear > to be much interest in these, but I may be wrong. (I will be getting > around to replying to the last round of comments on the 3.0 strawman > soon, as I have spare time again as of today). The problem I see with these kinds of additions is that there are dozens of different capability options which may or may not be useful to DB API users and adding a new attribute or method for each and every one of them doesn't seem like the right approach. mxODBC has a few .getXXXoption() style methods which allows retreiving this information from the database. I don't think we can come up with a standard extension here, though. > Anyway, the proposal seems good from my point of view. Thanks for > the effort :-) Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Fri Oct 26 13:56:40 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 26 Oct 2001 14:56:40 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <668B25DE-C9D0-11D5-B697-000393031882@shangri-la.dropbear.id.au> Message-ID: <3BD95D88.ED86A9E@lemburg.com> Stuart Bishop wrote: > > On Thursday, October 25, 2001, at 10:37 PM, Matthew T. Kromer wrote: > > > > > On Thursday, October 25, 2001, at 06:52 AM, Stuart Bishop wrote: > > > >> > >> > >> I also would like the connection method: > >> quote(object) > >> > >> Returns a SQL quoted version of the given variable as a > >> string, suitable for execution by the database backend. > >> For example: > >> > > > Since the primary reason you want quoting is generally to handle cases > > where you can't directly BIND values to your database, I'm of the > > opinion that this should be heavily leaned against. Instead, use of > > parameter binding should be highly encouraged. > > Definitely encouraged, which is is best done with documentation. The two > things I do with > this sort method (using Perl is a past life, and now Zope) are: > - Generate logs of SQL commands sent to the RDBMS. > - Generate hairy single use SQL dynamically for data mining type > reports. > > > I would be open to having extension methods which helped construct > > statements using the API's preferred bind specification method, or a > > mechanism whereby the application can negotiate with the adapter to > > choose a quoting mechanism. > > A different method of getting this functionality would be: > sql(command,params) > > >>> con.sql('SELECT * FROM users WHERE username = :p1',('zen',)) > > This would be useful for the first case I mentioned, but more obtuse for > the second case > since I would end up doing ''' con.sql(':p1',('zen',)) ''' to retrieve > the quoted parameter. mxODBC has a method called .nativesql() which pretty much implements this feature (the ODBC driver is usually the part in the chain which does the quoting, etc. before passing the data on to the database), however, .nativesql() will only return data if you have previously .prepare()ed it. Also, the methods are cursor methods, not connection ones. I'd suggest to leave this out of the spec and use a helper like e.g. dbinfo.py (see Python Softare below) for this. > > Having said all of that, this makes me lean towards a bilevel (or > > trilevel) approach where there is a standard module which all adapters > > subclass, and an optional module to attempt to provide further adapter > > abstractions (inter-adapter abstractions). However, I'd leave the > > current API spec largely untouched except for DRIVER level features; > > APPLICATION level features (including application convenience > > functions) belong elsewhere. > > This is similar to the approach the DB API 3.0 strawman I put out a few > months ago was > heading for. I think this sort of thing is beyond the scope of > Marc-Andre's proposal > as it stands (although he may decide to grow it). I'm taking the stand here that the DB API itself should be minimal and that DB authors should add as much to the interface as they feel necessary. The reason I started this discussion is to provide at least some of these extensions with a common understanding. Having a single implementation which then gets subclassed could be possible in Python 2.2 with the new type mechanism in place, but I think we should punt on it for at least a few years until subclassing C types has become stable enough to rely on it. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Fri Oct 26 13:49:40 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 26 Oct 2001 14:49:40 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <1004022272.27003.42.camel@chef.comstar.net> <003601c15d7d$d24e0c30$3b380f0a@divine.com> Message-ID: <3BD95BE4.76DFBFE0@lemburg.com> brian zimmer wrote: > > What happens in the case of: > > cur.execute("insert into x values (?, ?)", [(a, b), (c, d)]) > > I presume the .lastrowid is the value of the insert with (c, d)? You get a TypeError ;-) .execute() only supports sequence arguments, not sequences of sequences. .executemany() is meant for the latter. Now back to your question: > What happens in the case of: > > cur.executemany("insert into x values (?, ?)", [(a, b), (c, d)]) > > I presume the .lastrowid is the value of the insert with (c, d)? Good Point ! I would presume that too -- except: how do you know that the database maintains the order of the arguments that you presented ? Some optimizer might feel like adding (a,b) last... -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Fri Oct 26 13:46:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 26 Oct 2001 14:46:04 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <3BD58704.AEE57769@lemburg.com> <1004021976.26785.37.camel@chef.comstar.net> Message-ID: <3BD95B0C.F3A9577@lemburg.com> Andy Dustman wrote: > > On Tue, 2001-10-23 at 11:04, M.-A. Lemburg wrote: > > > Cursor Attribute .rownumber > > Now implemented in MySQLdb (was cursor._pos). > > > Cursor Method .scroll(value[,mode='relative']) > > Currently I have cursor.seek() and cursor.tell(), which work as the file > object methods. Hmm, not a bad idea... following the file interface here (except that .tell() is already available through .rownumber). > > Cursor Attribute .messages > > Connection Attribute .messages > > Not really sold on these yet, particularly the last one. Presently you > can turn Warnings off, and look at cursor._info (or connection.info()) > for the last message. The error handling callback thingie I mentioned in one of the replies would go a long way here... it basically provides a way for the user to add her own error handler which then raises exceptions, adds messages to the list etc. The reason I added the above attributes is to give these handlers a standard location to put their messages and the user a standard place to look for them. About connection.messages -- you may not need this since you only support one database, in mxODBC however there can be a whole number of different databases connected to the system, and then there's the ODBC manager which deals with these too, so connection.messages is really important for mxODBC (esp. at connection time, since so many things can go wrong at that stage due to misconfigurations etc.). Thanks for you input, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From bzimmer@ziclix.com Fri Oct 26 14:48:04 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Fri, 26 Oct 2001 08:48:04 -0500 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD95BE4.76DFBFE0@lemburg.com> Message-ID: What's the reasoning behind having .execute and .executemany? In zxJDBC, I (apparently erroneously) allow .execute to behave like .executemany. It doesn't affect anything functionally and minimizes the client requirement to check if you have multiple bound parameters, no? brian > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Friday, October 26, 2001 7:50 AM > To: brian zimmer > Cc: Andy Dustman; DB-SIG @ Python.org > Subject: Re: [DB-SIG] Optional DB API Extensions > > > brian zimmer wrote: > > > > What happens in the case of: > > > > cur.execute("insert into x values (?, ?)", [(a, b), (c, d)]) > > > > I presume the .lastrowid is the value of the insert with (c, d)? > > You get a TypeError ;-) .execute() only supports sequence arguments, > not sequences of sequences. .executemany() is meant for the latter. > > Now back to your question: > > > What happens in the case of: > > > > cur.executemany("insert into x values (?, ?)", [(a, b), (c, d)]) > > > > I presume the .lastrowid is the value of the insert with (c, d)? > > Good Point ! > > I would presume that too -- except: how do you know that the database > maintains the order of the arguments that you presented ? Some > optimizer might feel like adding (a,b) last... > > -- > Marc-Andre Lemburg > CEO eGenix.com Software GmbH > ______________________________________________________________________ > Consulting & Company: http://www.egenix.com/ > Python Software: http://www.lemburg.com/python/ > From andy@dustman.net Fri Oct 26 14:57:58 2001 From: andy@dustman.net (Andy Dustman) Date: 26 Oct 2001 09:57:58 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD95B0C.F3A9577@lemburg.com> References: <3BD58704.AEE57769@lemburg.com> <1004021976.26785.37.camel@chef.comstar.net> <3BD95B0C.F3A9577@lemburg.com> Message-ID: <1004104678.28992.9.camel@chef.comstar.net> On Fri, 2001-10-26 at 08:46, M.-A. Lemburg wrote: > Andy Dustman wrote: > > > > On Tue, 2001-10-23 at 11:04, M.-A. Lemburg wrote: > > > > > Cursor Attribute .rownumber > > > > Now implemented in MySQLdb (was cursor._pos). > > > > > Cursor Method .scroll(value[,mode='relative']) > > > > Currently I have cursor.seek() and cursor.tell(), which work as the file > > object methods. > > Hmm, not a bad idea... following the file interface here (except > that .tell() is already available through .rownumber). Generally speaking, I think I prefer methods to read-only attributes. The Db-API interface of MySQLdb is written in Python, and I'd rather not have to deal with __setattr__/__getattr__ hooks if I don't have to. Plus it is arguably better practice for a user interface. > > > Cursor Attribute .messages > > > Connection Attribute .messages Similar, why not cursor.messages(), which returns a list of messages generates, and clears the list, and the same for connection.messages(). -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From matt@zope.com Fri Oct 26 15:08:47 2001 From: matt@zope.com (Matthew T. Kromer) Date: Fri, 26 Oct 2001 10:08:47 -0400 Subject: [DB-SIG] Optional DB API Extensions References: Message-ID: <3BD96E6F.1070404@zope.com> brian zimmer wrote: >What's the reasoning behind having .execute and .executemany? In zxJDBC, I >(apparently erroneously) allow .execute to behave like .executemany. It >doesn't affect anything functionally and minimizes the client requirement to >check if you have multiple bound parameters, no? > >brian > There are a few reasons I can think of. Firstly, execute() is pretty clearly intended to execute once only; so I would think that should the API be able to take an array bind, that argument lists or tuples in an execute() should be converted to an array. In the executemany() form, lists would represent the range of values over which to execute (ie repeat the statement). Secondly, what happens if you execute('select * from emp where empid = :1', ((10, 20, 30, 40)))? Some implementations might generate a LIST of result sets, but there are cases where repeat execution as implicit behavior leads to undefined or unexpected results. The multiple-execute behavor of execute() is sadly a vestige of API 1.0, something I dont like but am pretty much stuck with though. I get just as put out trying to be overly-pythonic, ie where the signature of the method calls for one and only one parameter, so you have to pass in lists. I would argue that cursor.execute("select * from emp where empid = :1 and mgrid = :2", 10, 20) is more readable than cursor.execute("select * from emp where empid = :1 and mgrid = :2", (10, 20)) And the latter is the API 2.0 form. As an adapter author, I actually try to support both notations, largely out of personal preference, yet there are potential ambiguities. From ronny.de_winter@alcatel.be Fri Oct 26 15:55:19 2001 From: ronny.de_winter@alcatel.be (ronny.de_winter@alcatel.be) Date: Fri, 26 Oct 2001 16:55:19 +0200 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie Message-ID: <3BD97957.E015EF51@alcatel.be> This is a multi-part message in MIME format. --------------19BB433F915A26EEA47BFFA4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Can somebody give me some small examples on how to connect to a MS SQLServer / mySQL database and run a Query on it. Thanks, Ronny De Winter --------------19BB433F915A26EEA47BFFA4 Content-Transfer-Encoding: 7bit Content-Type: text/x-vcard; charset=us-ascii; name="ronny.de_winter.vcf" Content-Description: Card for Ronny De Winter Content-Disposition: attachment; filename="ronny.de_winter.vcf" begin:vcard n:De Winter;Ronny tel;fax:+ 32 3 451 60 60 tel;work:+ 32 3 450 33 71 x-mozilla-html:TRUE url:http://aww.sebb.bel.alcatel.be/~rdwi/ org:BND - DSL Software Group;WD23 adr:;;de Villermonstraat 38;Kontich;;2550;Belgium version:2.1 email;internet:ronny.de_winter@alcatel.be title:Process Engineer fn:Ronny De Winter end:vcard --------------19BB433F915A26EEA47BFFA4-- From mal@lemburg.com Fri Oct 26 15:57:23 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 26 Oct 2001 16:57:23 +0200 Subject: [DB-SIG] Optional DB API Extensions References: <3BD58704.AEE57769@lemburg.com> <1004021976.26785.37.camel@chef.comstar.net> <3BD95B0C.F3A9577@lemburg.com> <1004104678.28992.9.camel@chef.comstar.net> Message-ID: <3BD979D3.87FE3297@lemburg.com> Andy Dustman wrote: > > On Fri, 2001-10-26 at 08:46, M.-A. Lemburg wrote: > > Andy Dustman wrote: > > > > > > On Tue, 2001-10-23 at 11:04, M.-A. Lemburg wrote: > > > > > > > Cursor Attribute .rownumber > > > > > > Now implemented in MySQLdb (was cursor._pos). > > > > > > > Cursor Method .scroll(value[,mode='relative']) > > > > > > Currently I have cursor.seek() and cursor.tell(), which work as the file > > > object methods. > > > > Hmm, not a bad idea... following the file interface here (except > > that .tell() is already available through .rownumber). > > Generally speaking, I think I prefer methods to read-only attributes. > The Db-API interface of MySQLdb is written in Python, and I'd rather not > have to deal with __setattr__/__getattr__ hooks if I don't have to. Plus > it is arguably better practice for a user interface. But didn't you write that you have the .rownumber implemented already ? Since this attribute only has to be updated whenever you use .fetch...() or .scroll(), there's really no need to have an extra method for it, well, IMHO. After some more thinking I also found that I like .scroll() better than .seek() and .tell(). The reason is that in database terms, cursors "scroll", they don't "seek" ;-) (also, I like string arguments more than hard-to-remember integer options). What do you think -- should it be .seek() or .scroll() ? > > > > Cursor Attribute .messages > > > > Connection Attribute .messages > > Similar, why not cursor.messages(), which returns a list of messages > generates, and clears the list, and the same for connection.messages(). But exposing the plain lists should be very simple on DB API writers and its also very useful for DB users that way, since they already know how to manipulate lists (we don't have to invent a new interface for these tasks). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From nigel-c@clear.net.nz Fri Oct 26 22:08:37 2001 From: nigel-c@clear.net.nz (Nigel Campbell) Date: Sat, 27 Oct 2001 10:08:37 +1300 (NZDT) Subject: [DB-SIG] SQLserver and mySQL examples for a newbie (fwd) Message-ID: <20011026210837.8982F8024@tigger.localdomain> > Can somebody give me some small examples on how to connect to a > MS SQLServer / mySQL database and run a Query on it. mySQL has been dealt with at length elsewhere on the mailing list, but here is a brief rundown on SQL Server on Windows. There is a DB-API package for ODBC. If you get the ActiveState distribution (www.activestate.com), it comes with that. From memory, it also lives on Vaults of Parnassus. This will work with SQL server via ODBC. You make up a normal ODBC connect string and this will connect to the database. Alternatively, there are resources on how to connect using ADO on the web that you can find off google. I haven't done this, but the sites did have examples. I do have a little hello world level snippet on my machine at work somewhere that I did when experimenting with this. If there's any interest, I'll dig it out and post it to this list. Nigel From andy@dustman.net Fri Oct 26 22:22:05 2001 From: andy@dustman.net (Andy Dustman) Date: 26 Oct 2001 17:22:05 -0400 Subject: [DB-SIG] Optional DB API Extensions In-Reply-To: <3BD979D3.87FE3297@lemburg.com> References: <3BD58704.AEE57769@lemburg.com> <1004021976.26785.37.camel@chef.comstar.net> <3BD95B0C.F3A9577@lemburg.com> <1004104678.28992.9.camel@chef.comstar.net> <3BD979D3.87FE3297@lemburg.com> Message-ID: <1004131325.28992.80.camel@chef.comstar.net> On Fri, 2001-10-26 at 10:57, M.-A. Lemburg wrote: > Andy Dustman wrote: > > Generally speaking, I think I prefer methods to read-only attributes. > > The Db-API interface of MySQLdb is written in Python, and I'd rather not > > have to deal with __setattr__/__getattr__ hooks if I don't have to. Plus > > it is arguably better practice for a user interface. > > But didn't you write that you have the .rownumber implemented > already ? Well, yeah, but it was cursor._pos, i.e. a private member, not intended to be exposed to the user, or rather, it was exposed via cursor.tell(). I just renamed it to be rownumber because it was easy... But the main issue here was not so much cursor.rownumber but cursor.messages vs cursor.messages(), especially since to clear out messages, you have to del cursor.messages[:], as I recall... In MySQLdb, you can write to cursor.rownumber, and it will work, provided it's in range, and you are using the default Cursor. But using cursor.seek() always works (although some cursor types are not seekable). I'm (mostly) ambivalent about scroll() vs. seek(). > > > > > Cursor Attribute .messages > > > > > Connection Attribute .messages > > > > Similar, why not cursor.messages(), which returns a list of messages > > generates, and clears the list, and the same for connection.messages(). > > But exposing the plain lists should be very simple on DB API writers > and its also very useful for DB users that way, since they already know > how to manipulate lists (we don't have to invent a new interface > for these tasks). Calling cursor.messages(), which returns a list of messages since the last call, seems pretty simple to me, and no need to trim the list in a separate operation. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From daniel.dittmar@sap.com Fri Oct 26 22:46:50 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 26 Oct 2001 23:46:50 +0200 Subject: [DB-SIG] Optional DB API Extensions Message-ID: > After some more thinking I also found that I like .scroll() better than > .seek() and .tell(). The reason is that in database terms, cursors > "scroll", they don't "seek" ;-) (also, I like string arguments more > than hard-to-remember integer options). And why not relative () and absolute ()? Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Sat Oct 27 16:20:26 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 27 Oct 2001 17:20:26 +0200 Subject: [DB-SIG] Optional DB API Extensions References: Message-ID: <3BDAD0BA.955F8A53@lemburg.com> "Dittmar, Daniel" wrote: > > > After some more thinking I also found that I like .scroll() better than > > .seek() and .tell(). The reason is that in database terms, cursors > > "scroll", they don't "seek" ;-) (also, I like string arguments more > > than hard-to-remember integer options). > > And why not relative () and absolute ()? ... because the main idea is to move the cursor in the result set and absolute vs. relative are merely modes of how to express the move. Note that I chose 'relative' as default because those databases which do not support client side cursors will most likely only implement forward scrolls by a relative number of rows. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Sat Oct 27 16:07:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 27 Oct 2001 17:07:00 +0200 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie References: <3BD97957.E015EF51@alcatel.be> Message-ID: <3BDACD94.15717D49@lemburg.com> ronny.de_winter@alcatel.be wrote: > > Can somebody give me some small examples on how to connect to a > MS SQLServer / mySQL database and run a Query on it. Here are some hints for Windows [and a shameless plug for mxODBC ;-)]: Provided you have installed the ODBC drivers for MS SQL and MySQL, just get mxODBC, install it and then try: from mx.ODBC import Windows as DBI db = DBI.DriverConnect('DSN=datasourcename;UID=username;PWD=password') cursor = db.cursor() cursor.execute('select * from mytable') aList = cursor.fetchall() BTW, the Win32 book on Python by Mark Hammond and Andy Dustman has a very good introduction on how to connect to databases. On Unix things work more or less the same, but you have to install the ODBC manager first and then setup the datasources according to the ODBC manager docs. The most popular ODBC managers for Unix are www.iODBC.org and www.unixODBC.org. mxODBC works with both of them in pretty much the same way as on Windows except that the first line becomes: from mx.ODBC import iODBC as DBI -or- from mx.ODBC import unixODBC as DBI -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From andy@dustman.net Sat Oct 27 17:42:42 2001 From: andy@dustman.net (Andy Dustman) Date: 27 Oct 2001 12:42:42 -0400 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie In-Reply-To: <3BDACD94.15717D49@lemburg.com> References: <3BD97957.E015EF51@alcatel.be> <3BDACD94.15717D49@lemburg.com> Message-ID: <1004200963.31230.7.camel@chef.comstar.net> On Sat, 2001-10-27 at 11:07, M.-A. Lemburg wrote: > ronny.de_winter@alcatel.be wrote: > > > > Can somebody give me some small examples on how to connect to a > > MS SQLServer / mySQL database and run a Query on it. > BTW, the Win32 book on Python by Mark Hammond and Andy Dustman > has a very good introduction on how to connect to databases. I think you mean "have", not "has". I'm not co-author on that book... In any case, there are examples in the MySQLdb docs. If you are using fairly recent versions of MySQLdb and Python, you can use pydoc as well. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy You can have my keys when you pry them from my dead, cold neurons. From mal@lemburg.com Sat Oct 27 21:55:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 27 Oct 2001 22:55:04 +0200 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie References: <3BD97957.E015EF51@alcatel.be> <3BDACD94.15717D49@lemburg.com> <1004200963.31230.7.camel@chef.comstar.net> Message-ID: <3BDB1F28.CF19D9A3@lemburg.com> Andy Dustman wrote: > > On Sat, 2001-10-27 at 11:07, M.-A. Lemburg wrote: > > ronny.de_winter@alcatel.be wrote: > > > > > > Can somebody give me some small examples on how to connect to a > > > MS SQLServer / mySQL database and run a Query on it. > > > BTW, the Win32 book on Python by Mark Hammond and Andy Dustman > > has a very good introduction on how to connect to databases. > > I think you mean "have", not "has". I'm not co-author on that book... Sorry, the co-author was Andy Robinson... my mistake. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From jleach@mail.ocis.net Sun Oct 28 17:58:22 2001 From: jleach@mail.ocis.net (Jason C. Leach) Date: Sun, 28 Oct 2001 09:58:22 -0800 Subject: [DB-SIG] Re: DB-SIG digest, Vol 1 #506 - 2 msgs In-Reply-To: ; from db-sig-request@python.org on Sun, Oct 28, 2001 at 12:01:00PM -0500 References: Message-ID: <20011028095822.F7286@yukon.drivingbeat.com> hi, Is it possible to open a Sybase (bla.db) file from Python? j. -- ...................... ..... Jason C. Leach .. PGP/GPG Public key at http://www.keyserver.net/ Key ID: 157BD48C From ronny.de_winter@alcatel.be Sun Oct 28 21:41:02 2001 From: ronny.de_winter@alcatel.be (ronny.de_winter@alcatel.be) Date: Sun, 28 Oct 2001 22:41:02 +0100 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie References: Message-ID: <3BDC7B6D.7325729@alcatel.be> This is a multi-part message in MIME format. --------------E46FCF8EE712B50F67F0474C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Thanks for the answers. MySQLdb works ok for me. With mxODBC i have problems: import mx.ODBC ImportError: No module named mx.ODBC Also during installation on NT (egenix-mx-commercial-2.0.3.win32-py2.1.exe) i encountered some error messages: Software\Microsoft\Windows\CurrentVersion\uninstall: could not open key egenix-mx-commercial-2.0.3.win32-py2.1: could not create key However the final message was: module successfully installed Best regards, Ronny De Winter --------------E46FCF8EE712B50F67F0474C Content-Transfer-Encoding: 7bit Content-Type: text/x-vcard; charset=us-ascii; name="ronny.de_winter.vcf" Content-Description: Card for Ronny De Winter Content-Disposition: attachment; filename="ronny.de_winter.vcf" begin:vcard n:De Winter;Ronny tel;fax:+ 32 3 451 60 60 tel;work:+ 32 3 450 33 71 x-mozilla-html:TRUE url:http://aww.sebb.bel.alcatel.be/~rdwi/ org:BND - DSL Software Group;WD23 adr:;;de Villermonstraat 38;Kontich;;2550;Belgium version:2.1 email;internet:ronny.de_winter@alcatel.be title:Process Engineer fn:Ronny De Winter end:vcard --------------E46FCF8EE712B50F67F0474C-- From mal@lemburg.com Mon Oct 29 08:30:57 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 29 Oct 2001 09:30:57 +0100 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie References: <3BDC7B6D.7325729@alcatel.be> Message-ID: <3BDD13C1.24DC75C3@lemburg.com> ronny.de_winter@alcatel.be wrote: > > Thanks for the answers. > > MySQLdb works ok for me. > > With mxODBC i have problems: > import mx.ODBC > ImportError: No module named mx.ODBC > > Also during installation on NT (egenix-mx-commercial-2.0.3.win32-py2.1.exe) > i encountered some error messages: > Software\Microsoft\Windows\CurrentVersion\uninstall: could not open key > egenix-mx-commercial-2.0.3.win32-py2.1: could not create key You must have admin rights on the machine and install the package as admin if you have installed Python in the same way. > However the final message was: module successfully installed Please check whether the files are all there in \Python21\mx and subdirs. If not, you are having a permission problem. Distutils packages install directly into the Python distribution per default and depending on how you've installed Python itself, you may run into trouble when installing extensions using some other user account. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From ronny.de_winter@alcatel.be Mon Oct 29 09:08:27 2001 From: ronny.de_winter@alcatel.be (ronny.de_winter@alcatel.be) Date: Mon, 29 Oct 2001 10:08:27 +0100 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie References: Message-ID: <3BDD1C8B.E4ED7AED@alcatel.be> This is a multi-part message in MIME format. --------------5BAADFCCF60DFDEDE33F4EA4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii "M.-A. Lemburg" wrote: > > You must have admin rights on the machine and install the package > as admin if you have installed Python in the same way. I don't have administrator rights, did install python without admin rights. > > However the final message was: module successfully installed > > Please check whether the files are all there in \Python21\mx > and subdirs. If not, you are having a permission problem. Distutils > packages install directly into the Python distribution per default > and depending on how you've installed Python itself, you may > run into trouble when installing extensions using some other > user account. Used the same account. The files are there in \Python21\mx. Don't understand what was different with MySQLdb, installation looked similar (in \Python21\MySQLdb) and it works. Ronny De Winter --------------5BAADFCCF60DFDEDE33F4EA4 Content-Transfer-Encoding: 7bit Content-Type: text/x-vcard; charset=us-ascii; name="ronny.de_winter.vcf" Content-Description: Card for Ronny De Winter Content-Disposition: attachment; filename="ronny.de_winter.vcf" begin:vcard n:De Winter;Ronny tel;fax:+ 32 3 451 60 60 tel;work:+ 32 3 450 33 71 x-mozilla-html:TRUE url:http://aww.sebb.bel.alcatel.be/~rdwi/ org:BND - DSL Software Group;WD23 adr:;;de Villermonstraat 38;Kontich;;2550;Belgium version:2.1 email;internet:ronny.de_winter@alcatel.be title:Process Engineer fn:Ronny De Winter end:vcard --------------5BAADFCCF60DFDEDE33F4EA4-- From mal@lemburg.com Mon Oct 29 11:33:24 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 29 Oct 2001 12:33:24 +0100 Subject: [DB-SIG] Optional DB API Extensions References: <3BD58704.AEE57769@lemburg.com> <1003882109.1278.6.camel@nenya> <3BD67141.356D6200@lemburg.com> <1003914270.2600.14.camel@nenya> <3BD69E4E.63A93EAD@lemburg.com> Message-ID: <3BDD3E84.6FEEC4E5@lemburg.com> Thanks for all your input. Here's an updated revision of the=20 document... PEP: ??? Title: Optional Database API Extensions Version: $Revision: 1.1 $ Author: mal@lemburg.com (Marc-Andr=E9 Lemburg) Status: Draft Type: Standards Track Python-Version: 2.3 Created: 23-Oct-2001 Post-History:=20 Abstract This pre-PEP should provide a discussion basis for an "Optional Extensions" section in the DB API 2.0 standard PEP 249. Feel free to add/change text as required. Problem Even though the DB API 2.0 standard already provides a multitude of APIs, there are some common situations where a database package writer will want to add features which are specific to the database, but which could also be implemented for other databases as well. This pre-PEP will collect these common extensions for subsequent inclusion in the DB API 2.0 standard. Note that all extensions will be marked "optional", meaning that database writers are free to implement them, but are not required to do so in order to have a DB API 2.0 compatible package. Proposed Common Extensions As with all DB API optional features, the database module authors are free to not implement these additional attributes and methods (using them will then result in an AttributeError), to raise a NotSupportedError in case the availability can only be checked at run-time. It has been proposed to make usage of these extensions optionally visible to the programmer by issuing Python warnings through the Python warning framework. To make this feature useful, the warning messages must be standardized in order to be able to mask them. These standard messages are referred to below as "Warning Message". Cursor Attribute .rownumber This read-only attribute should provide the current 0-based index of the cursor in the result set or -1 if the index cannot be determined. The index can be seen as index of the cursor in a sequence (the result set). The next fetch operation will fetch the row indexed by .rownumber in that sequence. Warning Message: "DB-API extension cursor.rownumber used" Connection Attributes .Error, .ProgrammingError, etc. All exception classes defined by the DB API standard should be exposed on the Connection objects are attributes (in addition to being available at module scope). These attributes simplify error handling in multi-connection environments. Warning Message: "DB-API extension connection. used" Cursor Attributes .connection This read-only attribute return a reference to the Connection object on which the cursor was created. The attribute simplifies writing polymorph code in multi-connection environments. Warning Message: "DB-API extension cursor.connection used" Cursor Method .scroll(value[,mode=3D'relative']) Scroll the cursor in the result set to a new position according to mode. =20 If mode is 'relative' (default), value is taken as offset to the current position in the result set, if set to 'absolute', value states an absolute target position. An IndexError should be raised in case a scroll operation would leave the result set. In this case, the cursor position is left undefined (ideal would be to not move the cursor at all). Note: This method should use native scrollable cursors, if available , or revert to an emulation for forward-only scrollable cursors. The method may raise NotSupportedErrors to signal that a specific operation is not supported by the database (e.g. backward scrolling). Warning Message: "DB-API extension cursor.scroll() used" Cursor Attribute .messages This is a Python list object to which the interface appends tuples (exception class, exception value) for all messages which the interfaces receives from the underlying database for this cursor. The list is cleared by all standard cursor methods calls (prior to executing the call) except for the .fetchXXX() calls automatically to avoid excessive memory usage and can also be cleared by executing "del cursor.messages[:]". All error and warning messages generated by the database are placed into this list, so checking the list allows the user to verify correct operation of the method calls. The aim of this attribute is to eliminate the need for a Warning exception which often causes problems (some warnings really only have informational character). Warning Message: "DB-API extension cursor.messages used" Connection Attribute .messages Same as cursor.messages except that the messages in the list are connection oriented. The list is cleared automatically by all standard connection methods calls (prior to executing the call) to avoid excessive memory usage and can also be cleared by executing "del connection.messages[:]". Warning Message: "DB-API extension connection.messages used" Cursor Method .next() =20 Return the next row from the currently executing SQL statement using the same semantics as .fetchone(). A StopIteration exception is raised when the result set is exhausted for Python versions 2.2 and later. Previous versions don't have the StopIteration exception and so the method should raise an IndexError instead. =20 Warning Message: "DB-API extension cursor.next() used" Cursor Method .__iter__() =20 Return self to make cursors compatible to the iteration protocol. Warning Message: "DB-API extension cursor.__iter__() used" Cursor Attribute .lastrowid This read-only attribute provides the rowid of the last modified row (most databases return a rowid only when a single INSERT operation is performed.) If the operation does not set a rowid or if the database does not support rowids, this attribute should be set to None. The semantics of .lastrowid are undefined in case the last executed statement modified more than one row, e.g. when using INSERT with .executemany(). Warning Message: "DB-API extension cursor.lastrowid used" Proposed Error Handling Extension In order to simplify error handling when dealing with databases, database module authors may choose to implement user defineable error handlers. This section describes a standard way of defining these error handlers. Cursor/Connection Attribute .errorhandler Read/write attribute which references an error handler to call in case an error condition is meat.=20 The handler must be a Python callable taking the following arguments: errorhandler(connection, cursor, errorclass, errorvalue) where connection is a reference to the connection on which the cursor operates, cursor a reference to the cursor (or None in case the error does not apply to a cursor), errorclass is an error class which to instantiate using error value as construction arguments. The standard error handler should add the error information to the appropriate .messages attribute (connection.messages or cursor.messages) and raise the exception defined by the given errorclass and errorvalue parameters. If no errorhandler is set (the attribute is None), the standard error handling scheme as outlined above, should be applied. Warning Message: "DB-API extension .errorhandler used" Cursors should inherit the .errorhandler setting from their connection objects. Scope This PEP only affects database modules/packages which adhere to the Python DB API 2.0 standard. Some of these extensions may become manditory features in future DB API standard versions. Copyright This document has been placed in the public domain. --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From mal@lemburg.com Mon Oct 29 10:39:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 29 Oct 2001 11:39:04 +0100 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie References: <3BDD1C8B.E4ED7AED@alcatel.be> Message-ID: <3BDD31C8.32713F22@lemburg.com> ronny.de_winter@alcatel.be wrote: > > "M.-A. Lemburg" wrote: > > > > You must have admin rights on the machine and install the package > > as admin if you have installed Python in the same way. > > I don't have administrator rights, did install python without admin rights. > > > > However the final message was: module successfully installed > > > > Please check whether the files are all there in \Python21\mx > > and subdirs. If not, you are having a permission problem. Distutils > > packages install directly into the Python distribution per default > > and depending on how you've installed Python itself, you may > > run into trouble when installing extensions using some other > > user account. > > Used the same account. The files are there in \Python21\mx. > Don't understand what was different with MySQLdb, installation looked > similar (in \Python21\MySQLdb) and it works. AFAIK, MySQLdb uses distutils just like mxODBC does, so there must be some other problem... Please run Python in verbose mode and check where the import of mx.ODBC.Windows fails: python -vv >>> import mx.ODBC.Windows Just to make sure: You did install egenix-mx-base *before* installing egenix-mx-commercial (the base package includes mxDateTime which is needed by the commercial one). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/ From daniel.dittmar@sap.com Mon Oct 29 12:39:24 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 29 Oct 2001 13:39:24 +0100 Subject: [DB-SIG] Optional DB API Extensions Message-ID: > > And why not relative () and absolute ()? > > ... because the main idea is to move the cursor in the result set > and absolute vs. relative are merely modes of how to express > the move. Understood, but not really accepted. I think these are different enough to warrant their own method. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From ronny.de_winter@alcatel.be Mon Oct 29 20:29:32 2001 From: ronny.de_winter@alcatel.be (ronny.de_winter@alcatel.be) Date: Mon, 29 Oct 2001 21:29:32 +0100 Subject: [DB-SIG] SQLserver and mySQL examples for a newbie References: Message-ID: <3BDDBC2C.5025BE4D@alcatel.be> "M.-A. Lemburg" wrote: > > Just to make sure: > You did install egenix-mx-base *before* installing > egenix-mx-commercial (the base package includes mxDateTime which is > needed by the commercial one). > Here is the mistake! After installing egenix-mx-base first it works. Thanks, Ronny De Winter From jleach@mail.ocis.net Mon Oct 29 23:41:48 2001 From: jleach@mail.ocis.net (Jason C. Leach) Date: Mon, 29 Oct 2001 15:41:48 -0800 Subject: [DB-SIG] Open up a Sybase .db file. In-Reply-To: ; from db-sig-request@python.org on Mon, Oct 29, 2001 at 12:01:01PM -0500 References: Message-ID: <20011029154148.R7286@yukon.drivingbeat.com> hi, Does anyone know if I can open a Sybase .db file from Python? Thanks, j. -- ...................... ..... Jason C. Leach .. PGP/GPG Public key at http://www.keyserver.net/ Key ID: 157BD48C From magnus@thinkware.se Tue Oct 30 01:49:04 2001 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Tue, 30 Oct 2001 02:49:04 +0100 Subject: [DB-SIG] Open up a Sybase .db file. In-Reply-To: <20011029154148.R7286@yukon.drivingbeat.com> References: Message-ID: <5.1.0.14.0.20011030023706.0239be18@mail.irrblosset.se> At 15:41 2001-10-29 -0800, Jason C. Leach wrote: >Does anyone know if I can open a Sybase .db file from Python? Sure, you can open ANY file from Python. Do you know how it's organized? Do I understand correctly that you want to read (or even write) from / to a Sybase database without using a Sybase server? I would think that is difficult. I don't think any of the commercial database vendors publish those kinds of file formats, and I imagine they will change from version to version. It is probably possible to extract data after a lot of investigation, but I would certainly not let anyone manipulate database files I depended on like that. I think the only sane way to manipulate a Sybase databse file is by using a Sybase database. Python can speak to a Sybase server using a Sybase DBI, see http://www.object-craft.com.au/projects/sybase/ or with mxODBC. -- Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From david.jay.jackson@wcox.com Tue Oct 30 18:09:16 2001 From: david.jay.jackson@wcox.com (Jackson) Date: Tue, 30 Oct 2001 11:09:16 -0700 Subject: [DB-SIG] MySQLdb +cgi Message-ID: <200110301109.AA396362038@wcox.com> I would appricate a little help with script below. The "node" field is being grabbed fine. But it's not being passwd to the db underneeth. Thanks. David #!/usr/bin/python import cgi, MySQLdb print "Content-Type: text/html\n" form = cgi.FieldStorage() if form.has_key("node"): host=form["node"].value print "

" print "Hostname: ",host print "

" db = MySQLdb,connect("localhost","davej","F10wer$","sirinfo") rca = db.cursor() rca = execute(""" insert into test(node) values(?) """,[host]) else: print "

Dis doesn't look right

" From bkline@rksystems.com Tue Oct 30 19:08:18 2001 From: bkline@rksystems.com (Bob Kline) Date: Tue, 30 Oct 2001 14:08:18 -0500 (EST) Subject: [DB-SIG] MySQLdb +cgi In-Reply-To: <200110301109.AA396362038@wcox.com> Message-ID: On Tue, 30 Oct 2001, Jackson wrote: > I would appricate a little help with script below. The "node" field > is being grabbed fine. But it's not being passwd to the db > underneeth. > ... > db = MySQLdb,connect("localhost", [authentication info omitted...] Could it be the comma between "MySQLdb" and "connect"? -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From david.jay.jackson@wcox.com Tue Oct 30 19:22:38 2001 From: david.jay.jackson@wcox.com (Jackson) Date: Tue, 30 Oct 2001 12:22:38 -0700 Subject: Revised: [DB-SIG] MySQLdb +cgi Message-ID: <200110301222.AA152764636@wcox.com> Ok -- Here's the corrected script. The host variable prints out fine, but it's still no updating db (Yep, I verified the username and password") What about the construction of the exicute statement? Do we need placeholders(?) or (%s)? Thanks, David --------------------------- Script --------------- #!/usr/bin/python import cgi, MySQLdb print "Content-Type: text/html\n" form = cgi.FieldStorage() if form.has_key("node"): host=form["node"].value print "

" print "Hostname: ",host print "

" db =SQLdb.connect("localhost","rca","rca1234","sirinfo") rca = db.cursor() rca.execute(""" insert into test(node)values(?)""",host) else: print "

Dis doesn't look right

" From bkline@rksystems.com Tue Oct 30 20:23:05 2001 From: bkline@rksystems.com (Bob Kline) Date: Tue, 30 Oct 2001 15:23:05 -0500 (EST) Subject: Revised: [DB-SIG] MySQLdb +cgi In-Reply-To: <200110301222.AA152764636@wcox.com> Message-ID: On Tue, 30 Oct 2001, Jackson wrote: > Ok -- > Here's the corrected script. The host variable prints out fine, but > it's still no updating db. Try using "MySQLdb" where you have "SQLdb." But before you try that, why don't you elminate the web stuff (which you've confirmed is working) and test your database interaction from the command line until you've convinced yourself that you've eliminated all the typos. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From paul@dubois.ws Tue Oct 30 21:04:17 2001 From: paul@dubois.ws (Paul DuBois) Date: Tue, 30 Oct 2001 15:04:17 -0600 Subject: Revised: [DB-SIG] MySQLdb +cgi In-Reply-To: <200110301222.AA152764636@wcox.com> References: <200110301222.AA152764636@wcox.com> Message-ID: At 12:22 PM -0700 10/30/01, Jackson wrote: >Ok -- >Here's the corrected script. The host variable prints out fine, >but it's still no updating db (Yep, I verified the username and >password") What about the construction of the exicute statement? >Do we need placeholders(?) or (%s)? > >Thanks, >David > >--------------------------- Script --------------- >#!/usr/bin/python >import cgi, MySQLdb >print "Content-Type: text/html\n" > >form = cgi.FieldStorage() >if form.has_key("node"): > host=form["node"].value > print "

" > print "Hostname: ",host > print "

" > db =SQLdb.connect("localhost","rca","rca1234","sirinfo") > rca = db.cursor() > rca.execute(""" insert into test(node)values(?)""",host) ? isn't the placeholder for MySQLdb. Try: rca.execute(""" insert into test(node)values(%s)""",(host,)) > > >else: > print "

Dis doesn't look right

" -- From jleach@mail.ocis.net Wed Oct 31 03:52:42 2001 From: jleach@mail.ocis.net (Jason C. Leach) Date: Tue, 30 Oct 2001 19:52:42 -0800 Subject: [DB-SIG] Open up a Sybase .db file. In-Reply-To: <5.1.0.14.0.20011030023706.0239be18@mail.irrblosset.se>; from magnus@thinkware.se on Tue, Oct 30, 2001 at 02:49:04AM +0100 References: <20011029154148.R7286@yukon.drivingbeat.com> <5.1.0.14.0.20011030023706.0239be18@mail.irrblosset.se> Message-ID: <20011030195242.A11139@yukon.drivingbeat.com> hi, What I have is an app developed with Powerbuilder. The app has a .db file and I would really like to get the data out of it. I asume it's in Sybase format, since they develope Powerbuilder. j. On Tue, Oct 30, 2001 at 02:49:04AM +0100, Magnus Lyck? wrote: > At 15:41 2001-10-29 -0800, Jason C. Leach wrote: > >Does anyone know if I can open a Sybase .db file from Python? > > Sure, you can open ANY file from Python. Do you know how it's > organized? > > Do I understand correctly that you want to read (or even write) > from / to a Sybase database without using a Sybase server? > > I would think that is difficult. I don't think any of the > commercial database vendors publish those kinds of file formats, > and I imagine they will change from version to version. It is > probably possible to extract data after a lot of investigation, > but I would certainly not let anyone manipulate database files > I depended on like that. > > I think the only sane way to manipulate a Sybase databse file is > by using a Sybase database. Python can speak to a Sybase server > using a Sybase DBI, see http://www.object-craft.com.au/projects/sybase/ > or with mxODBC. > > > -- > Magnus Lyckå, Thinkware AB > Älvans väg 99, SE-907 50 UMEÅ > tel 070-582 80 65, fax: 070-612 80 65 > http://www.thinkware.se/ mailto:magnus@thinkware.se > > > > -- ...................... ..... Jason C. Leach .. PGP/GPG Public key at http://www.keyserver.net/ Key ID: 157BD48C