From thierry@nekhem.com Thu Mar 1 11:42:04 2001 From: thierry@nekhem.com (Thierry MICHEL) Date: Thu, 1 Mar 2001 11:42:04 +0000 Subject: [DB-SIG] PoPy v2.0.1 user competency issues In-Reply-To: <20010228113237.Z29494@trufflehunter.avalongroup.net>; from tjg@exceptionalminds.com on Wed, Feb 28, 2001 at 11:32:37AM -0800 References: <20010228113237.Z29494@trufflehunter.avalongroup.net> Message-ID: <20010301114204.D439@nekhem.com> Hi, This problem is that postgresql exits the transaction when an error occurs. I prepare a patch to resolv this problem, I notice you and the DB-API list when it's fixed. Thanks. Best regards On Wed, Feb 28, 2001 at 11:32:37AM -0800, Timothy Grant wrote: > Hi all, > > Two things: > > First of all, I have a feeling my lack of knowledge about how a > database interface is supposed to work is hindering my ability > to understand why PoPy is misbehaving. > > Here's what I am doing: > > I get a large quantity of data from an external data source. > > I parse the data, and then build two SQL queries from it: one > that does an insert and one that does an update. > > I then attempt to do an insert in a try/except block. > > If the insert fails, I know that I have to do an update and I > execute the update in the except block. > > I started using this before I installed v2.0.1. I also turned > autocommit on. > > I get the feeling that while my code was running it was not > working correctly at all. > > I installed PoPy v2.0.1 and something happened to autocommit. > So I commented out all the lines having to do with autocommit > and proceeded on my merry way. Now, however, I get the > following output from my both my test programme and the "real" > programme. Could some one improve my understanding of how these > things are supposed to work, and what silliness I have > implemented? > > Posted below is the output from my programme, and then below > that the test script itself. > > Thanks for any input you may have. > > [homer rmls]$ ./test.py > Attempting Insert > Attempting Update > NOTICE: current transaction is aborted, queries ignored until > end of transaction block > > from PoPy import * > > #Database settings > dbname = 'foobar' > dbusername = 'tjg' > dbhost = 'localhost' > > TRUE=True=true=1 > > def main(): > db = connect('dbname=%s user=%s host=%s' % (dbname, > dbusername, dbhost)) > > sqlin = "insert into test values (11, 'Jennifer', '503-555-1212');" > sqlup = "update test set name = 'Jennifer' where id = 11;" > > try: > print 'Attempting Insert' > cr = db.cursor() > cr.execute(sqlin) > cr.close() > except: > print 'Attempting Update' > cr = db.cursor() > cr.execute(sqlup) > cr.close() > > db.commit() > > I have a feeling my vim newbieness may have messed up the > indentation on the above, though I'm not sure. > > > -- > Stand Fast, > tjg. > > Timothy Grant tjg@exceptionalminds.com > Red Hat Certified Engineer www.exceptionalminds.com > Avalon Technology Group, Inc. <>< (503) 246-3630 > >>>>>>>>>>>>>Linux, because rebooting is *NOT* normal<<<<<<<<< > >>>>This machine was last rebooted: 42 days 23:27 hours ago<< > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- Thierry MICHEL Nekhem Technologies France thierry@nekhem.com thierry@nekhem.fr thierry@gnue.org Agroparc Batiment A 200, rue Michel de Montaigne 84911 AVIGNON Cedex 09 Tel: +33(0)490840154 "Sainthood in the Church of Emacs requires living a life of purity, but in the Church of Emacs, this does not require celibacy." Richard Stallman. From echuck@mindspring.com Thu Mar 1 14:30:50 2001 From: echuck@mindspring.com (Chuck Esterbrook) Date: Thu, 01 Mar 2001 09:30:50 -0500 Subject: [DB-SIG] [ANNOUNCE] MiddleKit 0.1 (Webware for Python 0.5) Message-ID: <5.0.2.1.0.20010301092120.051c8420@mail.mindspring.com> Webware for Python is a suite of software components for developing object-oriented, web-based applications. The suite includes a component named MiddleKit which makes its debut in this release. MiddleKit documentation can be browsed online at: http://webware.sourceforge.net/Webware/MiddleKit/Docs/ The Webware home page is at: http://webware.sourceforge.net/ -Chuck From Claudius.Schnoerr@ddg.de Fri Mar 2 12:17:22 2001 From: Claudius.Schnoerr@ddg.de (=?iso-8859-1?Q?=22Schn=F6rr=2C_Claudius_Dr=2E=22?=) Date: Fri, 2 Mar 2001 13:17:22 +0100 Subject: [DB-SIG] A: Is there a version of DCOracle for Oracle-8.1.6 and Python-2.0 ? Message-ID: <30E10C5E4EE6D31181EF00508B8B5BBB1176F9@EXCHANGE-SERVER.ddg.de> Hello to all, Since I have received several questions up to now concerning this = problem from people who read my posted question, I think it may be of general interest that I got my solution run in the first trial by using the following configuration (However, I only need simple select = statements): - DCOracle2-alpha2 (http://www.zope.org/Members/matt/dco2) - SunOS 5.7 (=3DSolaris 2.7 ?) - Python 2.0 compiled with gcc-2.8.1, - Oracle 8.1.6 I didn't try further to get DCOracle-1.3.2 run together with = Oracle-8.1.6. With the right setup this should be possible, but the aforementioned solution is ok for me. I hope this information is helpful. Thank you for your feedback, Claudius ------------------------------------------------------------------------= - Dr.-Ing. Claudius Schnoerr DDG Gesellschaft fuer Verkehrsdaten = mbH Niederkasseler Lohweg 20 Tel: ++49-(0)211-52777-423 40547 Duesseldorf Fax: ++49-(0)211-52777-109 email: Claudius.Schnoerr@ddg.de =20 ------------------------------------------------------------------------= - > -----Urspr=FCngliche Nachricht----- > Von: Jochen Scheel [SMTP:J.Scheel@artemis-pharmaceuticals.de] > Gesendet am: Freitag, 2. M=E4rz 2001 12:19 > An: Claudius.Schnoerr@ddg.de > Betreff: DCOracle >=20 >=20 > Dear Dr. Schnoerr, >=20 > I noticed your posting with regard to DCOracle for Python2.0 / = Oracle > 8.1.6. >=20 > We have run into identical problems and have started to work on it = but > cannot provide a solution yet. I'd like to stay in touch to make sure > we're > not duplicating efforts. Have you been able to solve the problem, or > received any feedback from other parties working on this question? >=20 > Sincerely, >=20 > Jochen Scheel >=20 >=20 >=20 > = ---------------------------------------------------------------------- > This Mail has been checked for Viruses > Attention: Encrypted Mails can NOT be checked ! >=20 > * * * >=20 > Diese Mail wurde auf Viren ueberprueft > Hinweis: Verschluesselte Mails koennen NICHT geprueft werden ! > = ---------------------------------------------------------------------- From Anthony@COMPUTRONIX.com Wed Mar 7 15:02:53 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Wed, 7 Mar 2001 08:02:53 -0700 Subject: [DB-SIG] [Module] cx_Oracle Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A717.AF93A870 Content-Type: text/plain; charset="iso-8859-1" cx_Oracle --------- Module which permits access to Oracle databases using the Python Database API specification 2.0, including binds of PL/SQL tables (arrays). URL: http://www.computronix.com License: Open Source Categories: Database Interfaces Anthony Tuininga (atuining@computronix.com) ------_=_NextPart_001_01C0A717.AF93A870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Module] cx_Oracle

           &= nbsp;           &= nbsp;        = cx_Oracle          &nb= sp;           &nb= sp;         
           &= nbsp;           &= nbsp;        ---------

Module which permits access to = Oracle databases using the Python Database API specification 2.0, = including binds of PL/SQL tables (arrays).

       URL:  http://www.computronix.com

   License:  Open = Source

  Categories:  = Database Interfaces

Anthony Tuininga = (atuining@computronix.com)



------_=_NextPart_001_01C0A717.AF93A870-- From anand123abc@hotmail.com Wed Mar 7 16:50:02 2001 From: anand123abc@hotmail.com (Anand Patel) Date: Wed, 07 Mar 2001 16:50:02 -0000 Subject: [DB-SIG] INTO sql command Message-ID: Hi I don't know if anyone can help, but basically I am using python to connect to a database (MySQL). Within the database I have a table and wanted to use the INTO command to read info off the table and store it in a list one at a time. However, MySQL doesn't like the INTO command. I think I have got around this by: -cursor.execute('select url from web_table where web_tuple_num = 1') -url1 = cursor.fetchall() however, when I type: -url1[0] to access the first element, I get : ('www.breakbeat.co.uk',) and was wondering if there was someway of getting: www.breakbeat.co.uk without brackets and inverted commas. Any help would be useful Many thanks _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From jon+python-db-sig@unequivocal.co.uk Wed Mar 7 16:54:01 2001 From: jon+python-db-sig@unequivocal.co.uk (Jon Ribbens) Date: Wed, 7 Mar 2001 16:54:01 +0000 Subject: [DB-SIG] INTO sql command In-Reply-To: ; from anand123abc@hotmail.com on Wed, Mar 07, 2001 at 04:50:02PM -0000 References: Message-ID: <20010307165401.D25401@snowy.squish.net> Anand Patel wrote: > -url1[0] > to access the first element, I get : ('www.breakbeat.co.uk',) > > and was wondering if there was someway of getting: www.breakbeat.co.uk > without brackets and inverted commas. This is nothing to do with databases, this is basic understanding of Python. Try reading the tutorial. Or typing 'print url1[0][0]' instead. From ryanw@inktomi.com Wed Mar 7 20:07:02 2001 From: ryanw@inktomi.com (Ryan Weisenberger) Date: Wed, 07 Mar 2001 12:07:02 -0800 Subject: [DB-SIG] SQL query help Message-ID: <4.3.2.7.2.20010307120344.00b86100@inkt-3.inktomi.com> Does anyone know how to get at tables with spaces in the name? The Microsoft SQL Server 2000 demo database is loaded with tables with names like "Order Details". I've tried a few combinations: c.execute("select * from order details") c.execute("select * from order-details") c.execute("select * from order_details") c.execute("select * from 'order details'") c.execute("select * from order%20details") All of these return a syntax error from the SQL parser. Does anyone know the correct syntax for this? - Ryan From chris@onca.catsden.net Wed Mar 7 20:02:28 2001 From: chris@onca.catsden.net (chris@onca.catsden.net) Date: Wed, 7 Mar 2001 12:02:28 -0800 (PST) Subject: [DB-SIG] SQL query help In-Reply-To: <4.3.2.7.2.20010307120344.00b86100@inkt-3.inktomi.com> Message-ID: On Wed, 7 Mar 2001, Ryan Weisenberger wrote: > Does anyone know how to get at tables with spaces in the name? The > Microsoft SQL Server 2000 demo database is loaded with tables with names > like "Order Details". > > I've tried a few combinations: > c.execute("select * from order details") > c.execute("select * from order-details") > c.execute("select * from order_details") > c.execute("select * from 'order details'") > c.execute("select * from order%20details") > > All of these return a syntax error from the SQL parser. > > Does anyone know the correct syntax for this? I've no experiences with MS products, but PostGres allows you to quite identifier names with double quotes. (Single quotes are for strings) So, try something like select * from "order details" ("`-/")_.-'"``-._ 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 bsb@winnegan.de Wed Mar 7 20:16:25 2001 From: bsb@winnegan.de (Siggy Brentrup) Date: 07 Mar 2001 21:16:25 +0100 Subject: [DB-SIG] SQL query help In-Reply-To: <4.3.2.7.2.20010307120344.00b86100@inkt-3.inktomi.com> References: <4.3.2.7.2.20010307120344.00b86100@inkt-3.inktomi.com> Message-ID: <87ae6x2v3a.fsf@winnegan.de> "Ryan Weisenberger" writes: > Does anyone know how to get at tables with spaces in the name? The > Microsoft SQL Server 2000 demo database is loaded with tables with > names like "Order Details". > > > I've tried a few combinations: > c.execute("select * from order details") > c.execute("select * from order-details") > c.execute("select * from order_details") > c.execute("select * from 'order details'") > c.execute("select * from order%20details") Dunno if this works with SQL server, I'm using it with PostgreSQL c.execute('select * from "order details"') In PostgreSQL names in double quotes are case sensitive, YMMV HTH Siggy From fruhstuck@rutherfurd.net Wed Mar 7 20:21:33 2001 From: fruhstuck@rutherfurd.net (Oliver Rutherfurd) Date: Wed, 7 Mar 2001 15:21:33 -0500 Subject: Fw: [DB-SIG] SQL query help Message-ID: <020201c0a744$33f20e50$010511ac@f4izh1> Oops, I meant to reply to the list... ----- Original Message ----- From: "Oliver Rutherfurd" To: "Ryan Weisenberger" Sent: Wednesday, March 07, 2001 3:07 PM Subject: Re: [DB-SIG] SQL query help > maybe try square brackets? > > c.execute("select * from [order details]") > > -Ollie > > ----- Original Message ----- > From: "Ryan Weisenberger" > To: > Sent: Wednesday, March 07, 2001 3:07 PM > Subject: [DB-SIG] SQL query help > > > > Does anyone know how to get at tables with spaces in the name? The > > Microsoft SQL Server 2000 demo database is loaded with tables with names > > like "Order Details". > > > > I've tried a few combinations: > > c.execute("select * from order details") > > c.execute("select * from order-details") > > c.execute("select * from order_details") > > c.execute("select * from 'order details'") > > c.execute("select * from order%20details") > > > > All of these return a syntax error from the SQL parser. > > > > Does anyone know the correct syntax for this? > > > > - Ryan > > > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > > From jon+python-db-sig@unequivocal.co.uk Thu Mar 8 09:54:36 2001 From: jon+python-db-sig@unequivocal.co.uk (Jon Ribbens) Date: Thu, 8 Mar 2001 09:54:36 +0000 Subject: [DB-SIG] SQL query help In-Reply-To: ; from chris@onca.catsden.net on Wed, Mar 07, 2001 at 12:02:28PM -0800 References: <4.3.2.7.2.20010307120344.00b86100@inkt-3.inktomi.com> Message-ID: <20010308095436.A23120@snowy.squish.net> chris@onca.catsden.net wrote: > I've no experiences with MS products, but PostGres allows you to quite > identifier names with double quotes. ... and MySQL uses backticks (`) From Anthony@COMPUTRONIX.com Wed Mar 7 15:02:53 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Wed, 7 Mar 2001 08:02:53 -0700 Subject: [DB-SIG] [Module] cx_Oracle Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A717.AF93A870 Content-Type: text/plain; charset="iso-8859-1" cx_Oracle --------- Module which permits access to Oracle databases using the Python Database API specification 2.0, including binds of PL/SQL tables (arrays). URL: http://www.computronix.com License: Open Source Categories: Database Interfaces Anthony Tuininga (atuining@computronix.com) ------_=_NextPart_001_01C0A717.AF93A870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Module] cx_Oracle

           &= nbsp;           &= nbsp;        = cx_Oracle          &nb= sp;           &nb= sp;         
           &= nbsp;           &= nbsp;        ---------

Module which permits access to = Oracle databases using the Python Database API specification 2.0, = including binds of PL/SQL tables (arrays).

       URL:  http://www.computronix.com

   License:  Open = Source

  Categories:  = Database Interfaces

Anthony Tuininga = (atuining@computronix.com)



------_=_NextPart_001_01C0A717.AF93A870-- From ryanw@inktomi.com Thu Mar 8 18:52:06 2001 From: ryanw@inktomi.com (Ryan Weisenberger) Date: Thu, 08 Mar 2001 10:52:06 -0800 Subject: [DB-SIG] RE: SQL Query Help Message-ID: <4.3.2.7.2.20010308105055.00c09530@inkt-3.inktomi.com> Thanks everyone for your replies! The double quotes did the trick. - Ryan >Does anyone know how to get at tables with spaces in the name? The >Microsoft SQL Server 2000 demo database is loaded with tables with names >like "Order Details". > >I've tried a few combinations: >c.execute("select * from order details") >c.execute("select * from order-details") >c.execute("select * from order_details") >c.execute("select * from 'order details'") >c.execute("select * from order%20details") > >All of these return a syntax error from the SQL parser. > >Does anyone know the correct syntax for this? > >- Ryan From brunson@level3.net Fri Mar 9 23:04:01 2001 From: brunson@level3.net (Eric Brunson) Date: Fri, 9 Mar 2001 16:04:01 -0700 Subject: [DB-SIG] DCOracle2 Message-ID: <20010309160400.A22239@level3.net> DCOracle2 seems to have gotten rid of named bind parameters, keeping only the positional parameters. Anyone know why a decision was made to drop this functionality? -- Eric Brunson - brunson@level3.net - page-eric@level3.net "When governments fear the people there is liberty. When the people fear the government there is tyranny." - Thomas Jefferson From hme@informatik.uni-rostock.de Sat Mar 10 19:24:27 2001 From: hme@informatik.uni-rostock.de (hme@informatik.uni-rostock.de) Date: Sat, 10 Mar 2001 20:24:27 +0100 Subject: [DB-SIG] [ANNOUNCE] OpenIngres Module (DB API 2.0) Message-ID: <20010310202427.A19845@informatik.uni-rostock.de> Hello, You will a DB API 2.0 conforming module, that works with Ingres 6.4 and OpenIngres at http://www.informatik.uni-rostock.de/~hme/software/ Peace Holger -- Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group hm at GUUG.de, http://www.informatik.uni-rostock.de/~hme/ From andy@dustman.net Mon Mar 12 16:53:49 2001 From: andy@dustman.net (Andy Dustman) Date: Mon, 12 Mar 2001 11:53:49 -0500 (EST) Subject: [DB-SIG] MySQLdb moves to SourceForge Message-ID: I've put MySQLdb over at SourceForge, so now you can play with CVS versions. Since there is a memory leak in 0.3.3 that is fixed in CVS, this might be a good idea. ;) ZMySQLDA will be there soon as well. http://sourceforge.net/projects/mysql-python (not a good sign, my fingers keep wanting to type "sourceforget"...) -- Andy Dustman PGP: 0xC72F3F1D @ .net http://dustman.net/andy "Normally with carbonara you use eggs, but I used lobster brains instead." -- Masahiko Kobe (Iron Chef Italian): 30-year-old Giant Lobster Battle From carsten@signals.de Wed Mar 14 18:17:01 2001 From: carsten@signals.de (Carsten Gaschler) Date: Wed, 14 Mar 2001 19:17:01 +0100 Subject: [DB-SIG] use of cursors Message-ID: <3AAFB59D.BBB40C1@signals.de> hai, can anybody give me an example how to use a cursor class without raising warning messages? Carsten From guido@digicool.com Wed Mar 14 19:13:51 2001 From: guido@digicool.com (Guido van Rossum) Date: Wed, 14 Mar 2001 14:13:51 -0500 Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html Message-ID: <200103141913.OAA05155@cj20424-a.reston1.va.home.com> I suppose the request below is about this URL: http://www.python.org/topics/database/modules.html Who's in charge of that page? Should I just add this? --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Wed, 14 Mar 2001 17:45:15 +0100 From: Michele Comitini To: webmaster@python.org cc: fog@mixadlive.com, Paolo Comitini , Pierluigi Di Nunzio Subject: Adding a driver to http://www.python.org/topics/database/modules.html - --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Webmaster, I would like to know what should I do to add a new python module to the database module list. =20 The module is "psycopg" a DB-API 2.0 compliant driver for the Postgresql RD= BMS. It is designed to support heavily multithreaded python applications with lots of cursor. Cursors can be very short lived since the driver has an intelligent garbage system for reusing db connections at libpq level. Thre= ad safety is level 2. http://initd.org/Software/psycopg Thank you. Kind regards, Michele Comitini - --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6r6AbHygWwn5gTsIRAl9BAJ40Di+lxa5HNFw+1Y/3bSC4CKu24QCggTgW 1gyEXbfQ9qPOEWhqfHaYRNk= =lkKT - -----END PGP SIGNATURE----- - --d6Gm4EdcadzBjdND-- ------- End of Forwarded Message From akuchlin@mems-exchange.org Wed Mar 14 19:17:29 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 14 Mar 2001 14:17:29 -0500 Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html In-Reply-To: <200103141913.OAA05155@cj20424-a.reston1.va.home.com>; from guido@digicool.com on Wed, Mar 14, 2001 at 02:13:51PM -0500 References: <200103141913.OAA05155@cj20424-a.reston1.va.home.com> Message-ID: <20010314141729.I15434@ute.cnri.reston.va.us> On Wed, Mar 14, 2001 at 02:13:51PM -0500, Guido van Rossum wrote: >I suppose the request below is about this URL: > http://www.python.org/topics/database/modules.html >Who's in charge of that page? Should I just add this? I am; I'll add it. (Yikes! This is what now, the fourth Python PostgreSQL module?) --amk From mal@lemburg.com Wed Mar 14 19:24:17 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Mar 2001 20:24:17 +0100 Subject: [DB-SIG] Opinion License mxODBC-Module References: <3A9A30F6.481BF868@clondiag.com> <20010226100708.A15208@ute.cnri.reston.va.us> Message-ID: <3AAFC561.C67E8C57@lemburg.com> Andrew Kuchling wrote: > > On Mon, Feb 26, 2001 at 11:33:26AM +0100, Matthias Kirst wrote: > >- mxODBC , the quasi-standard ODBC - module has a commercial developer > >license which costs almost 1500 US$ > > The actual standard is the DB-API, and mxODBC just an implementation. > Marc-Andre is free to pursue whatever licensing he cares to with his > module, and I wish him the best of luck with it. (Though I suspect > charging for mxODBC will backfire and result in a resurgence of > competition as people implement one-off modules for their database > system of choice -- we'll see...) > > >What will happen to Python when all of the other modules like pyXML will > >switch to this licensing model ??!! > > Not likely to happen. PyXML was written by several people (4Suite, > Lars Marius Garshol, Martin von Loewis, etc.) and it would be unlikely > that we'd all agree to take it commercial. Perhaps I should clarify the reasons for moving from the MySQL- style license to the new more simple one: * The MySQL-license just didn't work out: I never received any payment even though I knew about people using the module in consulting and even in products. * mxODBC was never a free product. The MySQL-license basically means "if you make money with this, then the author should receive his share of it too". As mentioned above, this hasn't worked out for me. * Developing mxODBC and the other mx tools takes up a lot of time and can no longer fund this development myself (as I did in the last few years). * mxODBC is still free for non-commercial use (and always has been). * About the pricing: a single installation of mxODBC costs USD 75 -- I don't consider this bloated in any way. Matthias was probably referring to the developer license which allows redistribution of mxODBC together with products developed using this license. Since there are no additional licensing fees to pay, I again think that USD 1250 is very reasonable given the possibilities this opens for commercial software vendors. * The new pricing is much cheaper than for the pre-2.0.0 versions: under the MySQL license mxODBC cost USD 500 per installation and up to 10% of the product revenue. I am currently thinking about adding a special option for Open Source software which allows using mxODBC for free in those applications as well. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Mar 14 20:57:00 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 14 Mar 2001 21:57:00 +0100 Subject: [DB-SIG] Update: New mxODBC 2.0.0 Windows Installer Build Message-ID: <3AAFDB1C.8DDE58EC@lemburg.com> The Windows installer I announced two weeks ago (just before heading off to IPC9) had a bug which caused the .execute() statements to hang. The bug seems to have been caused by a problem in the distutils build process on Windows. A clean recompile solved the problem. Please redownload the egenix-mx-commercial-2.0.0.win32-py2.0.exe installer from my Python Pages. I have deliberately not altered the version number since nothing in the code itself has changed. Sorry for any inconvenience this may have caused -- the distutils build process is still very new (especially the distutils Windows installer written by Thomas Heller; thanks Thomas :). Feedback about the Windows installer should be directed to the Python distutils SIG mailing list (see python.org). Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mcm@mixadlive.com Thu Mar 15 19:07:48 2001 From: mcm@mixadlive.com (Michele Comitini) Date: Thu, 15 Mar 2001 20:07:48 +0100 Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html In-Reply-To: <20010314141729.I15434@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Wed, Mar 14, 2001 at 02:17:29PM -0500 References: <200103141913.OAA05155@cj20424-a.reston1.va.home.com> <20010314141729.I15434@ute.cnri.reston.va.us> Message-ID: <20010315200748.G12900@developers.mixadlive.com> I can see psycopg listed on the page. Thanks! On Wed, Mar 14, 2001 at 02:17:29PM -0500, Andrew Kuchling wrote: > On Wed, Mar 14, 2001 at 02:13:51PM -0500, Guido van Rossum wrote: > >I suppose the request below is about this URL: > > http://www.python.org/topics/database/modules.html > >Who's in charge of that page? Should I just add this? > > I am; I'll add it. (Yikes! This is what now, the fourth Python > PostgreSQL module?) Well psycopg _deserves_ to be on that page ;) Download it, try it and contribute, it is _free_ software. ciao, Michele From db3l@fitlinxx.com Thu Mar 15 20:14:08 2001 From: db3l@fitlinxx.com (David Bolen) Date: Thu, 15 Mar 2001 15:14:08 -0500 Subject: [DB-SIG] Opinion License mxODBC-Module Message-ID: <1DB8BA4BAC88D3118B2300508B5A552CD93399@mail.fitlinxx.com> M.-A. Lemburg [mal@lemburg.com] writes: > * mxODBC was never a free product. The MySQL-license basically > means "if you make money with this, then the author should receive > his share of it too". As mentioned above, this hasn't worked > out for me. I think there was also more of a "grey" area (by my reading) of whether or not mxODBC was integral to what a customer perceived as the product, or a tool used by a company external to the product. > * About the pricing: a single installation of mxODBC costs USD 75 > -- I don't consider this bloated in any way. Matthias was probably > referring to the developer license which allows redistribution > of mxODBC together with products developed using this license. > Since there are no additional licensing fees to pay, I again > think that USD 1250 is very reasonable given the possibilities > this opens for commercial software vendors. As someone who has gone the commercial route (the developer version), I will say that the new scheme at least made this possible. Under the old commercial pricing we would have had to drop mxODBC use because we couldn't justify the cost/benefit (we use it for remote management tools which have little direct visibility to the customer, but the product can be an $80,000-$100,000 installation, and we're debating $50/machine database client licenses as it is). Moving to an up front with royalty free distribution (which is very similar to other embedded environments or the Visual Studio sort of approach) is a much easier sell (bounded cost) commercially and one I had no problem with. The one risk that does exist with the commercial pricing is that an ADO route is still a competitor that is free, so the pricing range is not totally flexible. If I suddenly found myself with many more developers needing to be counted under the developer portion of the license, the tradeoff becomes less certain. But as it stands now, we are certainly yielding benefit from mxODBC, and in a commercial environment I have no qualms about some mechanism by which Marc-Andre benefits from our use of it. -- David /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l@fitlinxx.com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ From wilson@visi.com Fri Mar 16 05:12:39 2001 From: wilson@visi.com (Timothy Wilson) Date: Thu, 15 Mar 2001 23:12:39 -0600 (CST) Subject: [DB-SIG] PoPy docs Message-ID: Hi everyone, A student and I are working on a project to build an inventory system for our science dept. using PostgreSQL and PoPy (and eventually Zope). We're having a hard time finding documentation on PoPy. Any suggestions? I've looked over v2.0 of the API and that's helpful, but I can't even connect properly to the database. I've got PostgreSQL 7.0.x on Debian w/ Python 1.5.2 and PoPy 2.0.1. If I'm logged in to the machine, what would the connection syntax be? The database is called 'supplydb' and everything else is standard. Any pointers? -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.k12.mn.us/ | http://www.zope.org/ W. St. Paul, MN | | http://slashdot.org/ wilson@visi.com | | http://linux.com/ From bsb@winnegan.de Fri Mar 16 07:01:01 2001 From: bsb@winnegan.de (Siggy Brentrup) Date: 16 Mar 2001 08:01:01 +0100 Subject: [DB-SIG] PoPy docs In-Reply-To: References: Message-ID: <87ofv2cidf.fsf@winnegan.de> Timothy Wilson writes: > Hi everyone, > > A student and I are working on a project to build an inventory system for > our science dept. using PostgreSQL and PoPy (and eventually Zope). We're > having a hard time finding documentation on PoPy. Any suggestions? I've > looked over v2.0 of the API and that's helpful, but I can't even connect > properly to the database. > > I've got PostgreSQL 7.0.x on Debian w/ Python 1.5.2 and PoPy 2.0.1. If I'm > logged in to the machine, what would the connection syntax be? The database > is called 'supplydb' and everything else is standard. Any pointers? Just from the top of my head: import PoPy conn = PoPy.connect('dbname=supplydb') if you're running as a user allowed to connect to PostgreSQL. For the other connection parameters, UTSL :) apt-get source python-popy is your friend :) HTH Siggy -- Siggy Brentrup - bsb@winnegan.de - http://www.winnegan.de/ ****** ceterum censeo javascriptum esse restrictam ******* From fog@mixadlive.com Fri Mar 16 09:48:14 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Fri, 16 Mar 2001 10:48:14 +0100 Subject: DBAPI-2.0 examples [was Re: [DB-SIG] PoPy Docs] Message-ID: <20010316104814.A1000@mixadlive.com> hi, some quite complete examples on how to use a DBAPI-2.0 compliant database adapter can be found in the examples/ subdirectory of the psycopg distribution. we plan to make this set of examples a full suite to test DBAPI-2.0 compliance (see my next post...) anyway, you can get the examples from http://initd.org/Software/psycopg or by installing the python-psycopg debian package (apt-get it.) ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From darcy@druid.net Fri Mar 16 11:26:59 2001 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Fri, 16 Mar 2001 06:26:59 -0500 (EST) Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html In-Reply-To: <20010315200748.G12900@developers.mixadlive.com> "from Michele Comitini at Mar 15, 2001 08:07:48 pm" Message-ID: <20010316112659.295FA1A65@druid.net> Thus spake Michele Comitini > On Wed, Mar 14, 2001 at 02:17:29PM -0500, Andrew Kuchling wrote: > > On Wed, Mar 14, 2001 at 02:13:51PM -0500, Guido van Rossum wrote: > > >I suppose the request below is about this URL: > > > http://www.python.org/topics/database/modules.html > > >Who's in charge of that page? Should I just add this? > > > > I am; I'll add it. (Yikes! This is what now, the fourth Python > > PostgreSQL module?) > > Well psycopg _deserves_ to be on that page ;) > Download it, try it and contribute, it is _free_ software. Um, I believe all the Python/PostgreSQL modules, including mine which is distributed with PostgreSQL(*), are free. And for the record, we would still be happy if all of these talented people would contribute to PyGreSQL. I don't understand why they all felt that it was necessary to splinter the development like this. (*) When building PostgreSQL you can simply add --with-python to the configure flags to install PyGreSQL. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From fog@mixadlive.com Fri Mar 16 12:11:44 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Fri, 16 Mar 2001 13:11:44 +0100 Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html In-Reply-To: <20010316112659.295FA1A65@druid.net>; from darcy@druid.net on Fri, Mar 16, 2001 at 06:26:59AM -0500 References: <20010315200748.G12900@developers.mixadlive.com> <20010316112659.295FA1A65@druid.net> Message-ID: <20010316131144.A1601@mixadlive.com> Scavenging the mail folder uncovered D'Arcy J.M. Cain's letter: > > Um, I believe all the Python/PostgreSQL modules, including mine which > is distributed with PostgreSQL(*), are free. sure. i think michele's intention was *not* to hurt anyone. > And for the record, we would still be happy if all of these talented people > would contribute to PyGreSQL. I don't understand why they all felt that > it was necessary to splinter the development like this. we began to develop popy when psygresql and the zope adapter based on it crashed multiple times our production sites. i inspected pygresql code and, i beg pardon, i found it quite complex and intricate. sometimes the right thing to do is just to learn from errors, rm -fr everything and start from scratch. so we did, and we did again with psycopg, when we needed a *solid* and thread safe adapter. we are also implementing some other ideas (like user-defined type-converters) that are easiest to implement from scratch rather than adding to an existing framework. but we can contribute other ways: i am sure the testsuite i am writing will help al of us to write better db adapters. ciao, federico p.s. i really didn't want to mean that you---or anybody else is a bad coder. english is not my native language and i am sorry for errors and misinterpretations. -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From darcy@druid.net Fri Mar 16 12:18:49 2001 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Fri, 16 Mar 2001 07:18:49 -0500 (EST) Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html In-Reply-To: <20010316112659.295FA1A65@druid.net> "from D'Arcy J.M. Cain at Mar 16, 2001 06:26:59 am" Message-ID: <20010316121849.3FFA01A65@druid.net> Thus spake D'Arcy J.M. Cain > (*) When building PostgreSQL you can simply add --with-python to the > configure flags to install PyGreSQL. My mistake. That's in the upcoming version. You can do that if you get the current version of PostgreSQL. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From darcy@druid.net Fri Mar 16 12:23:26 2001 From: darcy@druid.net (D'Arcy J.M. Cain) Date: Fri, 16 Mar 2001 07:23:26 -0500 (EST) Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html In-Reply-To: <20010316131144.A1601@mixadlive.com> "from Federico Di Gregorio at Mar 16, 2001 01:11:44 pm" Message-ID: <20010316122326.789651A65@druid.net> Thus spake Federico Di Gregorio > Scavenging the mail folder uncovered D'Arcy J.M. Cain's letter: > > Um, I believe all the Python/PostgreSQL modules, including mine which > > is distributed with PostgreSQL(*), are free. > > sure. i think michele's intention was *not* to hurt anyone. I'm sure it wasn't. His words, however, suggested that his was the only free one. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From mcm@mixadlive.com Fri Mar 16 12:48:18 2001 From: mcm@mixadlive.com (Michele Comitini) Date: Fri, 16 Mar 2001 13:48:18 +0100 Subject: [DB-SIG] Michele Comitini: Adding a driver to http://www.python.org/topics/database/modules.html In-Reply-To: <20010316112659.295FA1A65@druid.net>; from darcy@druid.net on Fri, Mar 16, 2001 at 06:26:59AM -0500 References: <20010315200748.G12900@developers.mixadlive.com> <20010316112659.295FA1A65@druid.net> Message-ID: <20010316134818.C17423@developers.mixadlive.com> We simply needed a small module that was DB-API 2.0 compliant and despite of this made use of multiple connections to postgres. That worked with Zope Transaction Manager rolling back or committing when needed. That was the need we had and PyGreSQL did not satisfy us for fulfilling those task while in some others it did. I stressed _free_ because I like people to notice that some modules are free while some are not. No intention to hurt people feelings. I am glad that PyGreSQL it is free and I like that you stated it so now everyone on the list knows that better. The fact that there are so many _free_ modules for postgresql may help others choosing a great language such as Python and a great RDBMS such as PostgreSQL. ciao, michele On Fri, Mar 16, 2001 at 06:26:59AM -0500, D'Arcy J.M. Cain wrote: > Thus spake Michele Comitini > > On Wed, Mar 14, 2001 at 02:17:29PM -0500, Andrew Kuchling wrote: > > > On Wed, Mar 14, 2001 at 02:13:51PM -0500, Guido van Rossum wrote: > > > >I suppose the request below is about this URL: > > > > http://www.python.org/topics/database/modules.html > > > >Who's in charge of that page? Should I just add this? > > > > > > I am; I'll add it. (Yikes! This is what now, the fourth Python > > > PostgreSQL module?) > > > > Well psycopg _deserves_ to be on that page ;) > > Download it, try it and contribute, it is _free_ software. > > Um, I believe all the Python/PostgreSQL modules, including mine which > is distributed with PostgreSQL(*), are free. > > And for the record, we would still be happy if all of these talented people > would contribute to PyGreSQL. I don't understand why they all felt that > it was necessary to splinter the development like this. > > (*) When building PostgreSQL you can simply add --with-python to the > configure flags to install PyGreSQL. > > -- > D'Arcy J.M. Cain | Democracy is three wolves > http://www.druid.net/darcy/ | and a sheep voting on > +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From fog@mixadlive.com Fri Mar 16 12:52:57 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Fri, 16 Mar 2001 13:52:57 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications Message-ID: <20010316135257.B1601@mixadlive.com> Hi *, i am about to fix the lastest DBAPI-2.0 compliance quirks in psycopg and to write a test suite but i need some clarifications on some parts of the DBAPI. this will be a long post, sorry for that... 1/ cursors and transactions if a db support transactions, how two cursors derived from the same connection are supposed to see changes done to the db? if cursor A does an insert, is cursor B supposed to see the change suddenly or only after a commit() on the connection? imho, it would be better if the api specifies that a commit() is required, even if for the drivers that does not support transactions commit() is a no-op. 2/ nextset() and executemany() the api is not very clear on what a "set" is. it just says that not all db support "multiple result sets". imho, it is logical that a call to executemany() (with a SELECT operation) produces multiple sets. is this the right interpretation or multiple result sets are something different? what should happen if a SELECT is passed to executemany() and the driver does not support nextset()? 3/ constructor objects are the constructor objects (Date, Time, Binary) expected to return a valid *already quoted* string? and what method should return the string, __repr__() or __str__()? i'll bet on __str__ but i am not sure. a little example to better explain: if a generate the object as t = module.Time('13:23:00') and then cursor.execute("SELECT * FROM table WHERE time > %(time)s", {'time':t}) the string that gets passed to the db is "SELECT * FROM table WHERE time > '13:23:00'", right? (note the quotes...) 4/ closing connections closing a connection does an implicit commit() on it? this is important because, following the file object style, most drivers implicitly close() the connection when the object is collected by the gc and the user can find the program commiting changes even if it did not tell it to. 5/ the description field how are the precision and scale field to be interpreted? are the fields mandatory? sometimes obtaining the information in the description is plain slow (like the display_size, you have to scan every single row in the result set) or requires accessing system tables. very few programs use the most esoteric fields (most programs only use type_code and name.) what about (i know that this will make people flame me) add a new method to obtain a detailed description and put a shorter description in the current .description field? thank you very much for your time, federico (expectiong comments) -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org All programmers are optimists. -- Frederick P. Brooks, Jr. From mal@lemburg.com Fri Mar 16 17:30:08 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 16 Mar 2001 18:30:08 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications References: <20010316135257.B1601@mixadlive.com> Message-ID: <3AB24D9F.BFD6EED9@lemburg.com> Federico Di Gregorio wrote: > > Hi *, > > i am about to fix the lastest DBAPI-2.0 compliance quirks in > psycopg and to write a test suite but i need some clarifications on > some parts of the DBAPI. this will be a long post, sorry for that... > > 1/ cursors and transactions > > if a db support transactions, how two cursors derived from the same > connection are supposed to see changes done to the db? if cursor A > does an insert, is cursor B supposed to see the change suddenly or > only after a commit() on the connection? imho, it would be better > if the api specifies that a commit() is required, even if for the > drivers that does not support transactions commit() is a no-op. This is left undefined in the DB API spec since database usually have their own specific idea about how to handle such a situation (it is called transaction isolation level in the ODBC docs). The transaction isolation level can be specified on a per connection basis if the ODBC driver supports this. Note that txn isolation is only an issue for the situation where you have one cursor e.g. adding data which could appear in the result set that another cursor currently fetches. > 2/ nextset() and executemany() > > the api is not very clear on what a "set" is. it just says that not > all db support "multiple result sets". imho, it is logical that a call > to executemany() (with a SELECT operation) produces multiple sets. > is this the right interpretation or multiple result sets are something > different? what should happen if a SELECT is passed to executemany() > and the driver does not support nextset()? No, .executemany() is there to allow passing multiple rows of arguments to the database in one go. The statement is then executed for each row of arguments binding those arguments to the parameter markers. Multiple result sets refer to the output format and only comes into play for stored procedure which may return multiple result sets. .nextset() then switches to the next available result set. > 3/ constructor objects > > are the constructor objects (Date, Time, Binary) expected to return > a valid *already quoted* string? and what method should return the > string, __repr__() or __str__()? i'll bet on __str__ but i am not > sure. a little example to better explain: if a generate the object > as t = module.Time('13:23:00') and then cursor.execute("SELECT * FROM > table WHERE time > %(time)s", {'time':t}) the string that gets > passed to the db is "SELECT * FROM table WHERE time > '13:23:00'", > right? (note the quotes...) The constructors are there to wrap the date/time value in a way which lets the interface tell the type. Just passing in a string wouldn't allow this. I'd recommend using mxDateTime for this purpose, since it was written to implement these constructors. > > 4/ closing connections > > closing a connection does an implicit commit() on it? this is important > because, following the file object style, most drivers implicitly close() > the connection when the object is collected by the gc and the user can > find the program commiting changes even if it did not tell it to. No. It should do an implicit .rollback() if possible. > 5/ the description field > > how are the precision and scale field to be interpreted? are the fields > mandatory? sometimes obtaining the information in the description is > plain slow (like the display_size, you have to scan every single row > in the result set) or requires accessing system tables. very few programs > use the most esoteric fields (most programs only use type_code and name.) > what about (i know that this will make people flame me) add a new method > to obtain a detailed description and put a shorter description in the > current .description field? These two fields can probably be safely set to None (mxODBC does this), since today 132-column printers and ASCII terminals for formatting result set outputs are not really relevant anymore ;-) > thank you very much for your time, > federico (expectiong comments) > > -- > Federico Di Gregorio > MIXAD LIVE Chief of Research & Technology fog@mixadlive.com > Debian GNU/Linux Developer & Italian Press Contact fog@debian.org > All programmers are optimists. -- Frederick P. Brooks, Jr. > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From fog@mixadlive.com Sat Mar 17 09:33:45 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Sat, 17 Mar 2001 10:33:45 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications In-Reply-To: <3AB24D9F.BFD6EED9@lemburg.com>; from mal@lemburg.com on Fri, Mar 16, 2001 at 06:30:08PM +0100 References: <20010316135257.B1601@mixadlive.com> <3AB24D9F.BFD6EED9@lemburg.com> Message-ID: <20010317103345.A831@mixadlive.com> hi and thenk you very much for your response, some dubts remain... Scavenging the mail folder uncovered M.-A. Lemburg's letter: > Federico Di Gregorio wrote: > > > > if a db support transactions, how two cursors derived from the same > > connection are supposed to see changes done to the db? if cursor A > > does an insert, is cursor B supposed to see the change suddenly or > > only after a commit() on the connection? imho, it would be better > > This is left undefined in the DB API spec since database usually > have their own specific idea about how to handle such a situation > (it is called transaction isolation level in the ODBC docs). The > transaction isolation level can be specified on a per connection > basis if the ODBC driver supports this. yes, i know what isolation level is. my question was about cursors *derived from the same connection*. now, as you say, isolation level, where vailable can be set on a "per connection" basis, so, are two cursors created from the *same* connection **required** to see the changes immediately or not? > > the api is not very clear on what a "set" is. it just says that not > > all db support "multiple result sets". imho, it is logical that a call > > to executemany() (with a SELECT operation) produces multiple sets. > > is this the right interpretation or multiple result sets are something > > different? what should happen if a SELECT is passed to executemany() > > and the driver does not support nextset()? > > No, .executemany() is there to allow passing multiple rows of > arguments to the database in one go. The statement is then executed > for each row of arguments binding those arguments to the parameter > markers. exactly as we implemented it in psycopg. > Multiple result sets refer to the output format and only comes > into play for stored procedure which may return multiple result > sets. .nextset() then switches to the next available result set. ok. now, how are multiple SELECTs derived from calling executemany() on a SELECT statement supposed to work? all the results should be concatenated into a single set? or we can extend .nextset() to cover this situation? > > 3/ constructor objects > > The constructors are there to wrap the date/time value in a > way which lets the interface tell the type. Just passing in a > string wouldn't allow this. i never said that i want to pass a simple string as the argument. my question was about how to implement type objects. > I'd recommend using mxDateTime for this purpose, since it was > written to implement these constructors. ok. so i wrap an mxDateTime object inside my Date, Time and TimeStamp objects. then, what method should return the quoted ready-to-be-inserted-into-db string? __reepr__()? __str__()? > > 4/ closing connections > > No. It should do an implicit .rollback() if possible. ok. that's what we do at now. > > 5/ the description field > > > > how are the precision and scale field to be interpreted? are the fields nobody knows what precision and scale are? i'll bet on number of significant digits for precision and number of digits to the right of the decimal point for scale, but that's *my* interpretation, and i really don't know how to extract both from the results the db backend sends to me. > > mandatory? sometimes obtaining the information in the description is > > plain slow (like the display_size, you have to scan every single row > > in the result set) or requires accessing system tables. very few programs > > use the most esoteric fields (most programs only use type_code and name.) > > what about (i know that this will make people flame me) add a new method > > to obtain a detailed description and put a shorter description in the > > current .description field? > > These two fields can probably be safely set to None (mxODBC does > this), since today 132-column printers and ASCII terminals > for formatting result set outputs are not really relevant anymore ;-) an api specification is there to provide uniformity. the answer "These two fields can probably be safely set to None" is, imho, not good *unless* the api specifies that the two fields are optional. this is why i am asking all that questions and why (in the future) i will probably propose a little revision of the API to clarify the obscure points. thank you again for your answer, ciao, federico p.s. a beginning of the test suite is available in the suite/ subdirectory of the psycopg package. the only well-implemented tests are, at now, the ones on type singletons (STRING, NUMBER, etc...) but i plan to have a full suite in a month or so. the suite will be included in psycopg 0.4.7 but if you want to contribute you can already get it from the cvs, see http://initd.org/Software/psycopg for more information on our cvs server. -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Best friends are often failed lovers. -- Me From bzimmer@ziclix.com Sat Mar 17 14:28:36 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Sat, 17 Mar 2001 08:28:36 -0600 Subject: [DB-SIG] DBAPI-2.0 clarifications In-Reply-To: <20010317103345.A831@mixadlive.com> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C0AEBC.4338E260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Federico, Thanks for asking some of the same questions I have while writing zxJDBC (http://www.ziclix.com/zxjdbc). Below I'll add a bit of follow up to what you asked. > > Scavenging the mail folder uncovered M.-A. Lemburg's letter: > > Federico Di Gregorio wrote: > > > > > > if a db support transactions, how two cursors derived from the same > > > connection are supposed to see changes done to the db? if cursor A > > > does an insert, is cursor B supposed to see the change suddenly or > > > only after a commit() on the connection? imho, it would be better > > > > This is left undefined in the DB API spec since database usually > > have their own specific idea about how to handle such a situation > > (it is called transaction isolation level in the ODBC docs). The > > transaction isolation level can be specified on a per connection > > basis if the ODBC driver supports this. > > yes, i know what isolation level is. my question was about cursors > *derived from the same connection*. now, as you say, isolation level, > where vailable can be set on a "per connection" basis, so, are two > cursors created from the *same* connection **required** to see the > changes immediately or not? > I believe they are required to see the changes immediately. Opening two connections is the only way to isolate the transactions. Essentially, and please correct me if I'm wrong, a cursor is only a statement from a connection and has no transactional ability on it's own, so the connection must handle them as all together or commit on each one. > > > the api is not very clear on what a "set" is. it just says that not > > > all db support "multiple result sets". imho, it is logical that a call > > > to executemany() (with a SELECT operation) produces multiple sets. > > > is this the right interpretation or multiple result sets are something > > > different? what should happen if a SELECT is passed to executemany() > > > and the driver does not support nextset()? > > > > No, .executemany() is there to allow passing multiple rows of > > arguments to the database in one go. The statement is then executed > > for each row of arguments binding those arguments to the parameter > > markers. > > exactly as we implemented it in psycopg. > > > Multiple result sets refer to the output format and only comes > > into play for stored procedure which may return multiple result > > sets. .nextset() then switches to the next available result set. > > ok. now, how are multiple SELECTs derived from calling executemany() > on a SELECT statement supposed to work? all the results should be > concatenated into a single set? or we can extend .nextset() to cover > this situation? I have the same question. Consider this example: >>> c = db.cursor() >>> c.execute("select b from x where id = ?", [(3,), (4,), (5,)]) >>> f = c.fetchall() What is the expected result? In zxJDBC it's implemented as such: >>> print f [(172,)] >>> c.nextset() >>> f = c.fetchall() >>> print f [(728,)] and so on. Or should it be: >>> print f [(172, 728, 827)] > > > 5/ the description field > > > > > > how are the precision and scale field to be interpreted? are the fields > > nobody knows what precision and scale are? i'll bet on number of significant > digits for precision and number of digits to the right of the decimal point > for scale, but that's *my* interpretation, and i really don't know how to > extract both from the results the db backend sends to me. > > > > mandatory? sometimes obtaining the information in the description is > > > plain slow (like the display_size, you have to scan every single row > > > in the result set) or requires accessing system tables. very few programs > > > use the most esoteric fields (most programs only use type_code and name.) > > > what about (i know that this will make people flame me) add a new method > > > to obtain a detailed description and put a shorter description in the > > > current .description field? > > > > These two fields can probably be safely set to None (mxODBC does > > this), since today 132-column printers and ASCII terminals > > for formatting result set outputs are not really relevant anymore ;-) > > an api specification is there to provide uniformity. the answer > "These two fields can probably be safely set to None" is, imho, not good > *unless* the api specifies that the two fields are optional. this is > why i am asking all that questions and why (in the future) i will probably > propose a little revision of the API to clarify the obscure points. > For what it's worth I set them to None as well. > thank you again for your answer, ciao, > federico > > p.s. a beginning of the test suite is available in the suite/ subdirectory > of the psycopg package. the only well-implemented tests are, at now, the > ones on type singletons (STRING, NUMBER, etc...) but i plan to have a full > suite in a month or so. the suite will be included in psycopg 0.4.7 but > if you want to contribute you can already get it from the cvs, see > http://initd.org/Software/psycopg for more information on our cvs server. > I've included my small testing framework as an example of how I test. I utilize PyUnit and can test just about any DB API 2.0 compliant implementation. I essentially read an xml document describing the factory method which opens the connection and then run the connection through any number of tests. It works in jython as well as cpython with no additional changes. Try changing the sample 'test.xml' to your factory method and see if it works, I'd be quite curious. It works perfectly well for mxODBC and zxJDBC at the moment as both are set in the xml document. try: D:\home\development\src\sourceforge\zxJDBC\src\test>python runner.py test.xml testing [mysql] checking connection ... ok checking simple queries with cursor.execute(), no parameters ... ok ------------------------------------------------------------------------------ Ran 2 tests in 0.230s OK Stay tuned for a new release of zxJDBC to coincide with some awesome changes to the Jython internals coming out with the 2.1 release. Finn rocked! thanks, brian ------=_NextPart_000_0000_01C0AEBC.4338E260 Content-Type: application/x-zip-compressed; name="test.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="test.zip" UEsDBBQAAAAIAH0/cSrXTMacVgQAAOMKAAANAAAAc2ltcGxldGVzdC5wea1WW0/bSBR+TqX+h6Oo FQ5yUycpoIVltSGFNrsU2FxUsQitJuNjMurY450ZQ8yv3zNjk0uBFQ+82ePvfOc713Gz2Xz7Brbh j9LOVQafmWUzZhDGOXKRCM6soOP+xRC67cghPfrdMN6H+4VFY9t5Gd5Cp93dhW4UdT5GvY+dXejs 7vd6+509mN2LNEUNx4sc3i3tByovtbiZWwgGLWcXwZEWLIO/K/Svtdnv94JLsWhzlf62NJ7MhYFc qxvNUqDHRCOCUYm9YxoPoFQFcKLSGAtjtZgVFkFYYFn8UWnPkKpYJKU7LLKY3Nk5gkWdGlCJf/ly NoUvmKFmEi6KmRQcTgXHzKC3Z+TfnZo5xjArvcmJUzGuVcCJImafuwNAQd813KI2LpddT1E7qllD UBoCZp14DSp3hi1SXIJkdmXbfjYHq1BjEJmnnqucopoTKcV5J6SEGUJhMClk6DkIDd+Hk6/n0wn0 zy7he3806p9NLg8ITc1AX/EWKy6R5lIQNcWmWWZLku8pvh2PBl/Jpn80PB1OLl0UJ8PJ2fF4DCfn I+jDRX80GQ6mp/0RXExHF+fj4zbAGJ2wKpXPZxoSYksVJTNGy4Q0q+gvqcSGFMoY5uwWqdQcxS3p Y8Cps15aRamyGx8roVfpPACRQKZsCHdaUOtY9bi+3n5V4xCGGW+HsPMLTJBShXAhGUf4AOPCUfR6 UQhHylgH/dYHiLqdTudDpxfthTAd9+vImm4W376hZCtNyV9w9I1glkdFJqybuZC6Nc0TIV3jGHoT KTpLLpkxYFy1cEK44MGg7d4GNNetfYdrxJiAQTvNA4MycYeNxiNsew3hAO6hHc/gEPwTV1mG3AYt z9jgy/NCG6UDb2J16bkbvI0L5NSeQTPWKgfaMpSlaoOI7Kbp0VXElUFOkVTET3FwjcyVZpMFAuG6 37rqQVZIGULGUoRbpvmc6aAbtUIw1lkuj+gk1yJluoQfWDqGVqtSs+5PUM9Q/olbbbqrPNSsLaKV BRoIOiFsOVS0RQ9Cbr0CZbem7DjKO/EalL2asuso7eI1KD/VlD1HydVrUO7UlJ9eL5e7NeWOV8le g3Kvptz9qTz10LgbLBW2mopEZEzKZVdzqQzWY+QG0yLTn9VdtjabTw7Xi2Zqjf5pMcuzRzDyeaYy XOp6GPiVLI220NkmyqvwmCpTNZIJ2uh/YnmsNelvZgpMwecVurmKfc7MP88wVL6ilZwqFU8kyUWz lqfakq8s58h/DKpoaL+uUdAG9h9drfkS4Pdyo0EbybVE7SIE6hGqPq2cNeSmj7HfxH8VqMtnnFS7 Gv4liKA28pdRpX1ZXNpQlK2c0dWE9C9gajUv3rcEInEksshssN2i3yWV/twljYTYeDtBS1tRyors IWCJWZC04PAQaK01cZG7WEk7VR20ums+43D7aU90Y7KVM+LYdOY+X0XXm97oZr/qXDtndNnd0HK/ eh9fN+E9BDX8f8fqP1BLAwQUAAAACAABP3Eq3Au2hOIEAADFCgAACQAAAHJ1bm5lci5weY1WbW/b NhD+3AL9DwehReVBVe1kwxBnGeZmSeOhTQ3bQREEgUFLlM2GEgWSTqL8+t2dXqyiKVB/MX28e+7t uaODIHj1En6D/yq/NQX8K7xYCydhUcpEZSoRXqF4MpvCQTwkTdZ+PU3HYHdFIW1cVtE9jOJDOBgO R++Hh+9HhzA6Gh8cjX8/gvWTynNp4eyxhNed+akpK6s2Ww/h6YDshrC2ShTQaP/VmP3zpBKtHuPE 5H93xsutclBas7EiBzxmVkpwJvMPwspjqMwOEoSyMlXOW7XeeQnKgyjS98YyQm5SlVUk3BUpuvNb CV7a3IHJ+MfHyyv4KDE5oWG2W2uVwCeVyMJJthfon6RuK1NYV2xyTlEsmijg3CAyl+4YpMJ7C/fS OirlAUM0jhrUCIyFUHgK3oIpyXCAEVeghd/bxj+twT7VFFTB0FtTYlZbBMU8H5TWsJawczLb6Ygx UBu+TpcXX66WMLm8hq+T+Xxyubw+Rm3kAt7Ke1ljqbzUCqExNysKX2H4DPH5bH56gTaTD9NP0+U1 ZXE+XV6eLRZw/mUOE5hN5svp6dWnyRxmV/PZl8VZDLCQFFhdyp9XGjJEyw0WM5VeKO322V9jix1G qFPYinuJrU6kusf4BCTIrF/tojbFhnNF7X05j0FlUBgfwYNVSB1vfuwv2+97HMG0SOII/jiCpcRS SZhpkUh4B4sdQRweDiP4YJwn1c8TgOHBaDR6Nzoc/hnB1WLSZBbQKL56icU2lqipvJcO43CVizCx IlMbJIojnVRmsFqh5moVIpt3GikkvLcnl6aQg/Grly8wCRLQ8cU3OKm1EbdnsNFmLbQLBxFok/Bp QOpW+p0tYINlR4TwWw1NV1I7yYhaOI+gNVLskB0+DOJgcPNudNuD+DWneEK4AeWV4MlhEZ2/kLqU HH6TK5YDYZzUGRZD0MzgptLScbYvSB6TGKOir05WK6G0PpAcS9Opx9hBscXdoGtnjVVP2taucf6D FcfNQWKLCpl4VqujykTija2ehWjuYk65ELnk2gu7oWBzUYZa5OtUwOMYHm9GtxH8aIrKu1wW3rFp 4x6t2841es+Z5hJHPO23W5SlrsIGBFuOgTxneCerB2NTt0+bC9s0hvMY91B7Pbihy9vObCvc6ldN Y1JGz2FTp5Yoc36BfkISXF6psX1+NBKsUHPqgsnFnVw5GtaWYVo8PT1HNKrvnp/hdwrcBRRcYpTk JVMat3fXyAjUCddSbQrca9hX2jO0r1XUjXuMzSP80xYnbEIJkq1M7oJ6REmz5UkvVDZgBVqegp8C 0qyZLeI9RXx7bm44A5bzqZF2PeKb7hffKm4h8wzpEvQmIqgrRQDfz5Hv/+51usudEueVGXLYe47h X42mMapI9C6V+0W3T7Xf43EbY1iXmI3ofRIxcYiLXgvbYEurCt87QkAxKHwibt642wDe4AMdd3Na u10TjuABaTyyT3K5jo0jf/x9coJ7m41bLTZPyHwd91pEH6YhVovT6RGzXSHJzRC3QYI7ATfnGic1 7tGPP716PjKZ6jkJBzHXkdBq5W6fP5e+u1Nl+Xz++EjRuNGv1Yqye7ta5UIVq9VbgktoCfN7FZ/y 10xYR/7pLs6kTEP8c4KRVI522D2vtwB5E1sp0voVIr40YSdtU1le59BaHoxvUfo/UEsDBBQAAAAI AMs+cSr9T4RTiwQAAI0NAAAIAAAAdGVzdC54bWztVltP4zgUfgaJ/3A2mgdYtWkKYkcLLbOlwNAR l24vQjwhN3FagxNnbadt+PV77KRN6bTASrtv+1I1x993vnPzpfFtHnGYUqmYiJtO3fWcb2d7u3u7 jV+q1b1d+BV+ZHoiYrggmoyIotBPqM9C5hONDGh1O3DoegZp0V86wQloqrSLfitTqLvHcOh59Zp3 VKsfg+edeF9Pjj0YvbIoohIu5wl8WbLbIskkG0807LcPDA+BkpEYCnSjoP3xynzO5q4vorMleTBh ChIpxpJEgH9DSSkoEeoZkfQUMpGCj64kDZjSko1STYFpIHFQE9J6iETAwswY0zhAOT2hmIuMFIjQ fny/G8J3GlNJOHTTEWc+3DCfxopaPkF9Y1UTGsAos5QrE0W/iAKuBHq2lTsFynBdLmoPh9ZFIVR4 rYCQsE+0CV6CSAzxACPOgBNdct2tNShTDYDF1vVEJJjVBJ1injPGOYwopIqGKa9YH4iGh87g+n44 gNbdIzy0er3W3eDxFNE4CrhKpzT3xaKEM3SNuUkS6wzDty5uL3vta+S0zjs3ncGjyeKqM7i77Pfh 6r4HLei2eoNOe3jT6kF32Ove9y9dgD41geWl3F5pCNFbJLCYAdWEcVVm/4gtVhghD2BCphRb7VM2 xfgI+DhZn+0iF/HY5orospynwEKIha7ATDIcHS1+7q/llz2uQCf23Qoc/w4DiqWi0OXEp1CFfmpc HB15FTgXShvobQvAO6zX69X6kfe1AsN+q8isWs13pNlW9t9OAxsQYBliEtGmE2XqL+7kKzsN32zS lQU3kFgD6YBQTSfWBreDsJD4WsgMfE4ULkRz9/7ivO0+MHQ8Uw5EFHsdNJ22iGPqL2g7DSLHaURj XUikkjswJTxdyD3lW9OpbSMouSRsBSWzYAPohWYzIYMC43NK5BNJtXjCYyBiesmoO6CzBP8wTLdg N2pFwsWnqaWtVChF1HSUmWRqjI4ZaiH1wjYwttxJo2YYn6rzM5mSLZXGYN3i+Ers0eoa8uv8B5a/ LLv/+bI/ByP/xIZwUqtx4RM+wZGq/Xd9WAMt8i5wQo7d8bN2o8jN63KRr29pBO4UMsEzmONx9m6F CpB7m/X/vDG30XVuWDpm49icCsV0TKj/MkzQO23jftSfI7Rv7s9bqo9HZjz+ENbNrhinS9jaRL3O 305T3uB/ME0YsMJT36f/7kTNt43UquC2Vt6aX1PKfg7csjUVldjxO/y/dLWcy22coHhfvGGtz/Bb Cl5am2b4LSjBEpnPj4HYpiUIT+bfPnGK/D+89gM7x81tGzYdTefafjoLzafSlIv5khJzf1rSyjI+ dPCNos0dC3GK7xJ7trMY8WZMK3gRs4jg2GPf9slBBUZguEv8QR6Y9XW2HlfIBVkPbMW2MbJyvQjN SFrj/nHl8OBdPdO7NbnStFFtubwiZmzvymgWrcuUps3lXiyvyBjbhzJKkyjZoLVi3ypYYtaS+1B5 xMXojejoqTRt0FtZXpEyLzpjf1cqeVkTWhg2yhSL60Nr1NjPw7ou3KjlLzi7g9Cev+z+BlBLAwQU AAAACADdPnEq5blGcRcFAAAIDgAACQAAAGNvbmZpZy5wea1X72/bNhD9nAD5Hw5GgciBqtrJhiHJ 2s3NktZDmhq2sy7LAoOWKZstJQok7VQt+r/v+EOWrMRtB/SbRd699+7xeExardbeLhzAn4VeiAz+ IJpMiaIwymnMEhYTzXC5N+jDYdQxkTb6SX92ArHIEjaP8iJcQTc6gsNOp/usc/SsewTd45PD45Of jmH6iaUplXD+MYcn6/QzkReSzRcagrO2yevAS8lIBv+46F992u+fWMzZxygW6Yt18njBFORSzCVJ AX8mklJQItH3RNJTKMQSYoSSdMaUlmy61BSYBpLNnglpEVIxY0lhFpfZDOn0goKmMlUgEvvx6uoa XtGMSsJhsJxyFsMli2mmqM0nyG9W1YLOYFrYlAujYuRVwIVAZGvdKVCG+xJWVCpj5aGF8EQeNQQh ISDaiJcgcpPYRsUFcKKr3GirB1WpM2CZhV6IHKtaICjWec84hymFpaLJkocWA6PhXX/8+u31GHpX N/CuNxz2rsY3pxiNvYC7dEUdFktzzhAaa5Mk0wXKtxBvzodnrzGn97J/2R/fmCou+uOr89EILt4O oQeD3nDcP7u+7A1hcD0cvB2dRwAjaoQ5K7c7DQmipQLNnFFNGFdV9Td4xAoV8hksyIriUceUrVAf wZ7Mi+89RS6yua0Voys7T4ElkAkdwr1k2DpaPDxfm1+dcQj9LI5C+PkYxhStojDgJKbwFEZLA3F0 1AnhpVDahL7pAXQOu93u0+5R55cQrkc9X1nLXMW9XTRbSA0fU87ZNITJZLpkXLNsMgnBUO/txpwo BRck1kIWJ3u7OzOaYBzLmJ5MAkV5EoKNyUiKvZVSPM5Z2wTumM1ovQfPq7j1rgvHLfdjvU7kfJnS TCvcur1bL3+gxb2QM7P6+Uul7gyHyBZpTpVQNUVezIYOYSCFWn+j12SBt5jjhXgOVyKrQhNnRXOZ zTPTPxtyNVXrCkqtf9FsJuRX1H5DaYy1NlzBKcrpA0/swBwQqagM3PlGf7+5dAvtLfwHBx/uHT/J c148yIvK+BBcRjsEzFgrWdniHpM3UZrEHzY3JJ2siPFXUjN1c8ZpIFv/PvkcRAe/tb+02qYaL9Mh e6FeokJFGjjNgjp5G14AXoFWJsCvtEy0pHopM6hH3j7t3tUojLMbBCuUZuNr9O0G88odSI3Uftcp fUiDzbfRBmFcEXoxdbq4bD3H4z/qTOuINQ+6LrVX78+YaC1VVaDrx8Cu3u6bVtu/e3CgEbYD/gpW 7Qaykfk47qPGmQLNZd2k87m3+0J5bm9ZSRs3aWvX8yH7FhfjxqX2nPa27N81CLyP3w2e4LKfkcEm 8Lo4N+F8gXFtjCT1Nid8WTZhCPbL8ZptSXMeqOXUrewkUqTwnqxIxAk+Ln6UjwqlaWoDfFe4lWhO 9UDiOy11YUCiuRTLPOjiDa5/OfsNb1mou6URBgVGQKmq3uBmoWFgOcAfOphUDlZ3wMLhW2jjogVR Exz1wb4ucrpflls9CmVfNNsISzQrwcYz5mMs1F07KPvSG+137Sdut50BlLsH5btYv4XYcMa/YT/S mPJZvN1Qdod4P8CRph/byb4O1LDBvZf/4/a6hPIQmvNqA9u8u49Ppq3o9qlunrC5YbUb7G6Y82ST z7xwD8mar18TXtKkhu5LqbAxtIZcjgEOTdiNh8XNNzsgvSDz0yVjG60fy1q+byNUEwIu+z86HmfZ +cpwx6nt/hK5RSjTD4FHcxoi819DHpgC/wNQSwECFAAUAAAACAB9P3Eq10zGnFYEAADjCgAADQAA AAAAAAABACAAtoEAAAAAc2ltcGxldGVzdC5weVBLAQIUABQAAAAIAAE/cSrcC7aE4gQAAMUKAAAJ AAAAAAAAAAEAIAC2gYEEAABydW5uZXIucHlQSwECFAAUAAAACADLPnEq/U+EU4sEAACNDQAACAAA AAAAAAABACAAtoGKCQAAdGVzdC54bWxQSwECFAAUAAAACADdPnEq5blGcRcFAAAIDgAACQAAAAAA AAABACAAtoE7DgAAY29uZmlnLnB5UEsFBgAAAAAEAAQA3wAAAHkTAAAAAA== ------=_NextPart_000_0000_01C0AEBC.4338E260-- From hme@informatik.uni-rostock.de Sat Mar 17 21:55:57 2001 From: hme@informatik.uni-rostock.de (hme@informatik.uni-rostock.de) Date: Sat, 17 Mar 2001 22:55:57 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications In-Reply-To: ; from brian zimmer on Sat, Mar 17, 2001 at 08:28:36AM -0600 References: <20010317103345.A831@mixadlive.com> Message-ID: <20010317225557.A23669@informatik.uni-rostock.de> You (brian zimmer) wrote: > Thanks for asking some of the same questions I have while writing zxJDBC (http://www.ziclix.com/zxjdbc). Below I'll add a bit of > follow up to what you asked. > > > Scavenging the mail folder uncovered M.-A. Lemburg's letter: > > > Federico Di Gregorio wrote: > > > > > > > > if a db support transactions, how two cursors derived from the same > > > > connection are supposed to see changes done to the db? if cursor A > > > > does an insert, is cursor B supposed to see the change suddenly or > > > > only after a commit() on the connection? imho, it would be better > > > > > > This is left undefined in the DB API spec since database usually > > > have their own specific idea about how to handle such a situation > > > (it is called transaction isolation level in the ODBC docs). The > > > transaction isolation level can be specified on a per connection > > > basis if the ODBC driver supports this. > > > > yes, i know what isolation level is. my question was about cursors > > *derived from the same connection*. now, as you say, isolation level, > > where vailable can be set on a "per connection" basis, so, are two > > cursors created from the *same* connection **required** to see the > > changes immediately or not? > > > > I believe they are required to see the changes immediately. Exactly. > Opening > two connections is the only way to isolate the transactions. Why would you isolate your program/transaction against what? The same program/transaction? There is no isolation within one thread of execution, one program or one transaction. It uses the same set of local variable, ... > Essentially, and please correct me if I'm wrong, a cursor is only a > statement from a connection and has no transactional ability on > it's own, so the connection must handle them as all together or > commit on each one. I could not see an useful application of having two connections to the same database and the same database system from one program. I mean, regardless of how many connections or cursors are open you are always in one program and one transaction. Okay, this gets different if multi-threading and nested transactions come into account. > > > > the api is not very clear on what a "set" is. it just says that not [...] My $.02 Holger -- Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group hm at GUUG.de, http://www.informatik.uni-rostock.de/~hme/ From fog@mixadlive.com Mon Mar 19 10:27:53 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Mon, 19 Mar 2001 11:27:53 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications In-Reply-To: <20010317225557.A23669@informatik.uni-rostock.de>; from hme@informatik.uni-rostock.de on Sat, Mar 17, 2001 at 10:55:57PM +0100 References: <20010317103345.A831@mixadlive.com> <20010317225557.A23669@informatik.uni-rostock.de> Message-ID: <20010319112753.D25491@mixadlive.com> Scavenging the mail folder uncovered hme@informatik.uni-rostock.de's letter: > > > yes, i know what isolation level is. my question was about cursors > > > *derived from the same connection*. now, as you say, isolation level, > > > where vailable can be set on a "per connection" basis, so, are two > > > cursors created from the *same* connection **required** to see the > > > changes immediately or not? > > > > > > > I believe they are required to see the changes immediately. > > Exactly. ok. thank you for the clarification. > > two connections is the only way to isolate the transactions. > > Why would you isolate your program/transaction against what? The same > program/transaction? There is no isolation within one thread of execution, > one program or one transaction. It uses the same set of local variable, ... dbapi defines various levels of thread safety. if your driver is safe at level 2 or greater a connection can be shared between multiple threads. maybe you want isolation between *threads*. > > Essentially, and please correct me if I'm wrong, a cursor is only a > > statement from a connection and has no transactional ability on > > it's own, so the connection must handle them as all together or > > commit on each one. > > I could not see an useful application of having two connections to the > same database and the same database system from one program. I mean, > regardless of how many connections or cursors are open you are always > in one program and one transaction. Okay, this gets different if > multi-threading and nested transactions come into account. nowdays multithreaded programs are the norm. and if you have a server that spawns a different thread for every client, you want isolation of the transactions... thanx, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Those who do not study Lisp are doomed to reimplement it. Poorly. -- from Karl M. Hegbloom .signature From fog@mixadlive.com Mon Mar 19 12:11:26 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Mon, 19 Mar 2001 13:11:26 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications In-Reply-To: ; from bzimmer@ziclix.com on Sat, Mar 17, 2001 at 08:28:36AM -0600 References: <20010317103345.A831@mixadlive.com> Message-ID: <20010319131126.G25491@mixadlive.com> Scavenging the mail folder uncovered brian zimmer's letter: > I believe they are required to see the changes immediately. Opening two > connections is the only way to isolate the transactions. Essentially, and > please correct me if I'm wrong, a cursor is only a statement from a > connection and has no transactional ability on it's own, so the connection > must handle them as all together or commit on each one. ok, this is clear. so what about putting this stuff in the DBAPI document? just to avoid unneccesary quastions on the same argument in the future... > > ok. now, how are multiple SELECTs derived from calling executemany() > > on a SELECT statement supposed to work? all the results should be > > concatenated into a single set? or we can extend .nextset() to cover > > this situation? > > I have the same question. Consider this example: [example snipped] can please the dbapi authors comment on this? thanx... [snip] > > "These two fields can probably be safely set to None" is, imho, not good > > *unless* the api specifies that the two fields are optional. this is > > why i am asking all that questions and why (in the future) i will probably > > propose a little revision of the API to clarify the obscure points. > > For what it's worth I set them to None as well. ok. lets say that all the fields, from 2 onward are optional and should be set to None if not implemented. what about putting this in the DBAPI? DBAPI editor? > I've included my small testing framework as an example of how I test. I > utilize PyUnit and can test just about any DB API 2.0 compliant > implementation. I essentially read an xml document describing the factory > method which opens the connection and then run the connection through any > number of tests. It works in jython as well as cpython with no additional > changes. Try changing the sample 'test.xml' to your factory method and see > if it works, I'd be quite curious. It works perfectly well for mxODBC and > zxJDBC at the moment as both are set in the xml document. looking at it, thank you very much, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From mal@lemburg.com Mon Mar 19 12:41:40 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 19 Mar 2001 13:41:40 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications References: <20010317103345.A831@mixadlive.com> <20010319131126.G25491@mixadlive.com> Message-ID: <3AB5FE84.3290B0B9@lemburg.com> Federico Di Gregorio wrote: > > Scavenging the mail folder uncovered brian zimmer's letter: > > > I believe they are required to see the changes immediately. Opening two > > connections is the only way to isolate the transactions. Essentially, and > > please correct me if I'm wrong, a cursor is only a statement from a > > connection and has no transactional ability on it's own, so the connection > > must handle them as all together or commit on each one. > > ok, this is clear. so what about putting this stuff in the DBAPI document? > just to avoid unneccesary quastions on the same argument in the future... Patches welcome ;-) > > > ok. now, how are multiple SELECTs derived from calling executemany() > > > on a SELECT statement supposed to work? all the results should be > > > concatenated into a single set? or we can extend .nextset() to cover > > > this situation? > > > > I have the same question. Consider this example: > [example snipped] > > can please the dbapi authors comment on this? thanx... I think the docs on .nextset() are clear about this. .fetchXXX() APIs only work on the current result set and a call .nextset() advances to the next available result set. Example (untested): cursor.execute('select * from mytable where id = ?', [(1,), (2,)]) resultsets = [] while 1: resultsets.append(cursor.fetchall()) if not cursor.nextset(): break resultsets ... [[(1,'first')], [(2,'second')]] > [snip] > > > "These two fields can probably be safely set to None" is, imho, not good > > > *unless* the api specifies that the two fields are optional. this is > > > why i am asking all that questions and why (in the future) i will probably > > > propose a little revision of the API to clarify the obscure points. > > > > For what it's worth I set them to None as well. > > ok. lets say that all the fields, from 2 onward are optional and should > be set to None if not implemented. what about putting this in the DBAPI? > DBAPI editor? Good idea. Could you send in patches for this ? > > I've included my small testing framework as an example of how I test. I > > utilize PyUnit and can test just about any DB API 2.0 compliant > > implementation. I essentially read an xml document describing the factory > > method which opens the connection and then run the connection through any > > number of tests. It works in jython as well as cpython with no additional > > changes. Try changing the sample 'test.xml' to your factory method and see > > if it works, I'd be quite curious. It works perfectly well for mxODBC and > > zxJDBC at the moment as both are set in the xml document. > > looking at it, thank you very much, > federico Perhaps we ought to put this somewhere on the db-sig page or into the database topic guide... Andrew ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From fog@mixadlive.com Mon Mar 19 12:54:16 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Mon, 19 Mar 2001 13:54:16 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications In-Reply-To: <3AB5FE84.3290B0B9@lemburg.com>; from mal@lemburg.com on Mon, Mar 19, 2001 at 01:41:40PM +0100 References: <20010317103345.A831@mixadlive.com> <20010319131126.G25491@mixadlive.com> <3AB5FE84.3290B0B9@lemburg.com> Message-ID: <20010319135416.B27077@mixadlive.com> hi, ok, i'll send you patches to the dbapi document to better clarify the "obscure points" (no offense intended to you as the editor ;). just a last comment, in your first answer to my original posting you said: Multiple result sets refer to the output format and only comes into play for stored procedure which may return multiple result sets. .nextset() then switches to the next available result set. now, this is a little different from: > I think the docs on .nextset() are clear about this. .fetchXXX() > APIs only work on the current result set and a call .nextset() > advances to the next available result set. the first seems to imply that .nextset() does not apply to the results of an .executemany() but only to the result sets generated by a stored procedure called via .callproc(). your example below tells the opposite. can i take the example as the right thing and send you a patch to the dbapi document for this one too? > cursor.execute('select * from mytable where id = ?', [(1,), (2,)]) ^^^^^^^ executemany(), right? > resultsets = [] > while 1: > resultsets.append(cursor.fetchall()) > if not cursor.nextset(): > break > > resultsets ... [[(1,'first')], [(2,'second')]] thank you very much, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org La felicità è una tazza di cioccolata calda. Sempre. -- Io From bzimmer@ziclix.com Mon Mar 19 13:11:39 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Mon, 19 Mar 2001 07:11:39 -0600 Subject: [DB-SIG] DBAPI-2.0 clarifications In-Reply-To: <20010319135416.B27077@mixadlive.com> Message-ID: > > hi, > > ok, i'll send you patches to the dbapi document to better clarify > the "obscure points" (no offense intended to you as the editor ;). just > a last comment, in your first answer to my original posting you said: > > Multiple result sets refer to the output format and only comes > into play for stored procedure which may return multiple result > sets. .nextset() then switches to the next available result set. > > now, this is a little different from: > > > I think the docs on .nextset() are clear about this. .fetchXXX() > > APIs only work on the current result set and a call .nextset() > > advances to the next available result set. > > the first seems to imply that .nextset() does not apply to the results > of an .executemany() but only to the result sets generated by a stored > procedure called via .callproc(). your example below tells the opposite. > can i take the example as the right thing and send you a patch to the > dbapi document for this one too? > > > cursor.execute('select * from mytable where id = ?', [(1,), (2,)]) > ^^^^^^^ > executemany(), right? > Why do we have an .executemany() when .execute() appears to solve the problem? I also think it makes it easier on the end user since they only have one method to use at any one time. My .executemany() just invokes .execute() which figures out whether the params are a sequence of sequences or not. > > resultsets = [] > > while 1: > > resultsets.append(cursor.fetchall()) > > if not cursor.nextset(): > > break > > > > resultsets ... [[(1,'first')], [(2,'second')]] > This is precisely what I expected to see. As for testing, I'd be greatly in favor of DB API 2.0-compliant test. I think it would help tremendously. thanks, brian From mal@lemburg.com Mon Mar 19 16:30:43 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 19 Mar 2001 17:30:43 +0100 Subject: [DB-SIG] DBAPI-2.0 clarifications References: Message-ID: <3AB63432.F0ACAAC7@lemburg.com> brian zimmer wrote: > > > > I think the docs on .nextset() are clear about this. .fetchXXX() > > > APIs only work on the current result set and a call .nextset() > > > advances to the next available result set. > > > > the first seems to imply that .nextset() does not apply to the results > > of an .executemany() but only to the result sets generated by a stored > > procedure called via .callproc(). your example below tells the opposite. > > can i take the example as the right thing and send you a patch to the > > dbapi document for this one too? > > > > > cursor.execute('select * from mytable where id = ?', [(1,), (2,)]) > > ^^^^^^^ > > executemany(), right? Right. My mistake. > > > > Why do we have an .executemany() when .execute() appears to solve the problem? I also think it makes it easier on the end user > since they only have one method to use at any one time. My .executemany() just invokes .execute() which figures out whether the > params are a sequence of sequences or not. No, .executemany() is needed to be clear about sequence of sequences... strings are sequences too and these would cause very strangs effects if used with .execute(). > > > resultsets = [] > > > while 1: > > > resultsets.append(cursor.fetchall()) > > > if not cursor.nextset(): > > > break > > > > > > resultsets ... [[(1,'first')], [(2,'second')]] > > > > This is precisely what I expected to see. Good :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From daniel.dittmar@sap.com Mon Mar 19 16:52:05 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 19 Mar 2001 17:52:05 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarification s) Message-ID: Whether executemany ('SELECT ...', [...]) returns one or multiple result sets, couldn't that be implementation dependant? Unless the client really wants to know which result record come from which input parameter record, it shouldn't really matter. Why is this a problem? When the database doesn't support array execution, implementing the notion of a single result set is at least cumbersome. When the database does support array execution, then returning multiple result sets is inefficient (because multiple SELECTs have to be executed + possibly the overhead of closing the result sets). In addition, it would require different handling for INSERTs/UPDATEs and SELECTs, which (depending on the underlying API) might require parsing the SQL. The client would have to expect multiple result sets. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Mon Mar 19 17:14:53 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 19 Mar 2001 18:14:53 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications) References: Message-ID: <3AB63E8D.523B5CEF@lemburg.com> "Dittmar, Daniel" wrote: > > Whether executemany ('SELECT ...', [...]) returns one or multiple result > sets, couldn't that be implementation dependant? Unless the client really > wants to know which result record come from which input parameter record, it > shouldn't really matter. > > Why is this a problem? > > When the database doesn't support array execution, implementing the notion > of a single result set is at least cumbersome. > > When the database does support array execution, then returning multiple > result sets is inefficient (because multiple SELECTs have to be executed + > possibly the overhead of closing the result sets). In addition, it would > require different handling for INSERTs/UPDATEs and SELECTs, which (depending > on the underlying API) might require parsing the SQL. > > The client would have to expect multiple result sets. I don't see your problem... if the DB does not support multiple result sets, then .nextset() can simply be left unimplemented or be implemented to always raise an exception (see the DB API). Note that the original idea behind .nextset() was to allow stored procedures to pass back multiple result sets. The idea of having .executemany() produce mutliple result sets only came up recently on the db-sig list -- I can't really say, that I like it... Snice it is not defined in the DB API spec, the feature is deemed to be implementation specific. Multiple selects in one execution block don't really make any sense if executed from within Python, since passing in query parameters is not preformance relevant and it only makes debugging code harder... IMHO, at least. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From bzimmer@ziclix.com Mon Mar 19 17:32:42 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Mon, 19 Mar 2001 11:32:42 -0600 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications) In-Reply-To: <3AB63E8D.523B5CEF@lemburg.com> References: Message-ID: <5.0.2.1.0.20010319112323.00ade588@ziclix.com> At 06:14 PM 3/19/2001 +0100, M.-A. Lemburg wrote: >Note that the original idea behind .nextset() was to allow >stored procedures to pass back multiple result sets. The idea >of having .executemany() produce mutliple result sets only came >up recently on the db-sig list -- I can't really say, that I like >it... Really? I do it all the time. Rather than building up a big "in (?, ?, ..., ?)" I create the single "= ?" and pass in the sequence of sequences. I reuse the prepared statement for each execution and build the results up for access in .nextset(). I do like it for the reason of knowing what fetched what and for minimizing having to do: inclause = "in (%s)" % (",".join(("?",)*len(params))) I could additionally include the id I'm querying in the result set, but I already have it. No big deal either way I guess, but I much prefer the .execute*() for select than building the in list. For what I do I haven't noticed any performance differences (content management primarily with Informix) and I like the syntax more. brian From daniel.dittmar@sap.com Mon Mar 19 17:37:40 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 19 Mar 2001 18:37:40 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) Message-ID: > I don't see your problem... if the DB does not support multiple > result sets, then .nextset() can simply be left unimplemented or > be implemented to always raise an exception (see the DB API). I could implement .executemany on SELECTs in two ways: - array execute, which would give one result set - loop over the input list to create multiple result sets Authors of databases without array execution also have two choices - loop over the input list to create multiple result sets - implement a smart result set which detects the end of one resultset and executes the SELECT with the next parameter list, thus giving the illusion of a single result set > Note that the original idea behind .nextset() was to allow > stored procedures to pass back multiple result sets. The idea Right. > Snice it is not defined in the DB API spec, the feature is deemed > to be implementation specific. Multiple selects in one execution > block don't really make any sense if executed from within Python, > since passing in query parameters is not preformance relevant and > it only makes debugging code harder... IMHO, at least. In contrast with array INSERTs/UPDATESs, array SELECts are a rather exotic feature. So standardizing it's behaviour in a way that requires additional work by the driver implementor is probably a waste of time. For those liking either behaviour, it's possible to write a db independant module for it. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From fog@mixadlive.com Mon Mar 19 18:07:45 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Mon, 19 Mar 2001 19:07:45 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications) In-Reply-To: <3AB63E8D.523B5CEF@lemburg.com>; from mal@lemburg.com on Mon, Mar 19, 2001 at 06:14:53PM +0100 References: <3AB63E8D.523B5CEF@lemburg.com> Message-ID: <20010319190745.B27341@mixadlive.com> Scavenging the mail folder uncovered M.-A. Lemburg's letter: > Note that the original idea behind .nextset() was to allow > stored procedures to pass back multiple result sets. The idea > of having .executemany() produce mutliple result sets only came > up recently on the db-sig list -- I can't really say, that I like > it... [snip] > Snice it is not defined in the DB API spec, the feature is deemed > to be implementation specific. Multiple selects in one execution right. that's why i started this thread ;) i think we need to formalize thing like this one a little more, to avoid *user* problems. if a programmer uses a dbapi compliant driver, she should as free as possible from thoughts like "mmm... *this* one returns multiple sets when i give a SELECT to executemany()? or does it return just a single set? or it just bombs out. or it returns the _last_ result?" > In contrast with array INSERTs/UPDATESs, array SELECts are a rather exotic > feature. So standardizing it's behaviour in a way that requires additional > work by the driver implementor is probably a waste of time. i better like a clear api that puts some burden on the driver's implementor but free the user/programmer from problems when switching from a driver to another one. a won't call helping the final user a "waste of time." ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org A short story: I want you. I love you. I'll miss you. -- Me From daniel.dittmar@sap.com Tue Mar 20 10:46:16 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Tue, 20 Mar 2001 11:46:16 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) Message-ID: > i better like a clear api that puts some burden on the driver's > implementor but free the user/programmer from problems when switching > from a driver to another one. a won't call helping the final user a > "waste of time." I think this is true only when the choosen standard is based on experience. Until then, I prefer - to document the behaviour as implementation defined - provide example code to achieve either behaviour which helps to gain experience - if after some time a consensus arises about the 'right' behaviour, then it can be put into the standard > a won't call helping the final user a > "waste of time." OK, change this to "relative waste of time because it is an exotic feature". There are other areas where users would profit from more standardization (different SQL dialects, BLOB handling), but where such a standardization could be achieved only through large efforts by the driver implementor at the possible cost of hiding the strength of the underlying database. But you can ignore all of the above if we can find a solution - which can be easily implemented by all drivers - which seems to be the 'right thing' - which doesn't hide the strength of some database implementations In this case (executemany of a SELECT), I see three possible alternatives a) multiple result sets, where each result sets matches to exactly one set of input parameters b) exactly one result set, which is the union of the SELECTs c) an undefined number of result sets with identical structure, where there is no defined relation between each result set and a specific set of input parameters I would strongly oppose a) - this kind of loop should be in application code - hides the array SELECT of SAP DB (and probably Oracle, ...) b) would be the most natural for SAP DB (well, after I implemented array commands), but it would require additional work by drivers who don't supply array commands c) seems to be a solution everybody could live with - databases supporting array commands create exactly one result set - databases without array commands would implement .nextset () by executing the next set of input parameters - but maybe: client code is more cumbersome because of the explicit .nextset () required Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From fog@mixadlive.com Tue Mar 20 11:04:28 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Tue, 20 Mar 2001 12:04:28 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) In-Reply-To: ; from daniel.dittmar@sap.com on Tue, Mar 20, 2001 at 11:46:16AM +0100 References: Message-ID: <20010320120427.C3502@mixadlive.com> Scavenging the mail folder uncovered Dittmar, Daniel's letter: > > I think this is true only when the choosen standard is based on experience. > Until then, I prefer > - to document the behaviour as implementation defined > - provide example code to achieve either behaviour which helps to gain > experience > - if after some time a consensus arises about the 'right' behaviour, then it > can be put into the standard i agree. [snip] > In this case (executemany of a SELECT), I see three possible alternatives > a) multiple result sets, where each result sets matches to exactly one set > of input parameters > b) exactly one result set, which is the union of the SELECTs > c) an undefined number of result sets with identical structure, where there > is no defined relation between each result set and a specific set of input > parameters both a and b seems good to me. can you explain what an "array select" is and why choosing (a) would "hide" it on sap and oracle? ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org La felicità è una tazza di cioccolata calda. Sempre. -- Io From daniel.dittmar@sap.com Tue Mar 20 11:34:29 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Tue, 20 Mar 2001 12:34:29 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) Message-ID: > can you explain what an "array select" is > and why choosing (a) would "hide" it on sap and oracle? The list of input parameter sets is sent to the database with one request, resulting in one result set (the union of the result sets for each individual parameter set). 'SELECT * from sometable where a = ? and b = ?' called with [(1, 2), (3, 4), (5, 6)] amounts to SELECT * from sometable where a = 1 and b = 2 UNION SELECT * from sometable where a = 3 and b = 4 UNION SELECT * from sometable where a = 5 and b = 6 Another example that was given is 'WHERE a in (?)', but allowing a variable number of elements of the list. This is of course more efficient than sending three SELECTs and fetching and closing three result sets. If the DB API standard would require to produce a separate result set for each input parameter set, then there would be no way to specify the behaviour described above, thus 'hiding' this feature. I must admit that it can rarely be used in real life because it's implemented as a UNION. 'SELECT * from sometable where a in (?) and b in (?)' called with [(1, 2), (3, 4), (5, 6)] is equivalent to the example above, not to SELECT * from sometable where a in (1, 3, 5) and b in (2, 4, 6) Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From fog@mixadlive.com Tue Mar 20 14:57:29 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Tue, 20 Mar 2001 15:57:29 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) In-Reply-To: ; from daniel.dittmar@sap.com on Tue, Mar 20, 2001 at 12:34:29PM +0100 References: Message-ID: <20010320155728.G3502@mixadlive.com> Scavenging the mail folder uncovered Dittmar, Daniel's letter: > > can you explain what an "array select" is > > and why choosing (a) would "hide" it on sap and oracle? [example snipped] > This is of course more efficient than sending three SELECTs and fetching and > closing three result sets. agreed. > If the DB API standard would require to produce a separate result set for > each input parameter set, then there would be no way to specify the > behaviour described above, thus 'hiding' this feature. i understand. so the problem is that *some* db can be made more efficient by choosing a certain solution while the others, missing UNION, will emulate it. given that a db missing UNION still has to do some bookeeping and and serialize the queries, i am beginning to think that returning a single set that is the sum of all the queries is the right thing. also, i can't see a case where returning different sets will help the application writer (he will use a for to cycle on the sets anyway, so he can just put the *select* inside the for.) is this a kind of resolution on executemany()? what do the others think? ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Don't dream it. Be it. -- Dr. Frank'n'further From LFu@Ceon.com Wed Mar 21 03:17:48 2001 From: LFu@Ceon.com (Lieyong Fu) Date: Tue, 20 Mar 2001 19:17:48 -0800 Subject: [DB-SIG] Sending control character through telnetlib Message-ID: <46FEE020BCB4D3118C5800508B55C9286905E6@SFOEXCHANGE> I'm trying to send a control character (Control-b character) using telnetlib. I tried telnet.write("\002") and telnet.sock.send("\002"). None of them seems to work. Any help is very appreciated. Thanks, Lieyong From mal@lemburg.com Wed Mar 21 09:58:54 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 21 Mar 2001 10:58:54 +0100 Subject: [DB-SIG] Sending control character through telnetlib References: <46FEE020BCB4D3118C5800508B55C9286905E6@SFOEXCHANGE> Message-ID: <3AB87B5E.CA4AB61C@lemburg.com> Lieyong Fu wrote: > > I'm trying to send a control character (Control-b character) using > telnetlib. I tried telnet.write("\002") and telnet.sock.send("\002"). None > of them seems to work. Any help is very appreciated. This is the Python database SIG. Please post your question to comp.lang.python or a more appropriate SIG instead. Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Wed Mar 21 10:28:37 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 21 Mar 2001 11:28:37 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) References: <20010320155728.G3502@mixadlive.com> Message-ID: <3AB88255.480E5FB9@lemburg.com> Federico Di Gregorio wrote: > > [using .executemany() with SELECT statements] > > > This is of course more efficient than sending three SELECTs and fetching and > > closing three result sets. > > agreed. -1 Like I said before, using .executemany() with SELECT is not a good practice. You lose too much control over what the DB does with the selects and errors will be not contain enough information to allow you to pinpoint the SELECT parameter set which failed. .executemany() was intended to be used with INSERT and UPDATE where many DBs offer array processing to speed up the process. For the SELECT case, please stick with separate calls to .execute(). Performance is really a non-issue here and keeping the SELECTs separated helps a lot in debugging code and making the overall experience clearer to the reader of the source code. If you really have to use SELECTs in .executemany() then the current definition of .nextset() will allow you to switch to the next result set in the queue, so you can still get at the different result sets. It does not make any sense to return the union of the result sets (since the same could be achieved with a single SELECT and multiple WHERE conditions). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From daniel.dittmar@sap.com Wed Mar 21 11:26:19 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Wed, 21 Mar 2001 12:26:19 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) Message-ID: > Like I said before, using .executemany() with SELECT is not > a good practice. Agreed in principle. Of course there are rare exceptions. > You lose too much control over what the > DB does with the selects and errors will be not contain enough > information to allow you to pinpoint the SELECT parameter > set which failed. > > .executemany() was intended to be used with INSERT and UPDATE > where many DBs offer array processing to speed up the process. Array INSERT and UPDATE have their problems too with regard to portability. When one parameter set fails, what should be the outcome - failure of the whole command? - execute succeeds up to the offending parameters? - should this be different for 'autocommit'? I guess each database will have one of these as the 'natural' implementation. Each database will have a hard time to implement the other one, possibly at the cost of not using the native capabilities, thus defying the whole purpose of array commands. > > For the SELECT case, please stick with separate calls to .execute(). > Performance is really a non-issue here and keeping the SELECTs > separated helps a lot in debugging code and making the overall > experience clearer to the reader of the source code. > This is advice for those using the DB standard, not those implementing it. > If you really have to use SELECTs in .executemany() then the > current definition of .nextset() will allow you to switch > to the next result set in the queue, so you can still get > at the different result sets. The point was: should the use of .nextset () be mandatory or is the driver/database allowed to put everything into one result set. > It does not make any sense to > return the union of the result sets (since the same could be > achieved with a single SELECT and multiple WHERE conditio But array parameters allow you to prepare it once and execute it with a variable number of input parameters. What I would suggest: Add a chapter 'Implementation defined features' to the standard. - this would allow to be specific about being non specific - that's a place to add example code which would implement a specific behaviour. For the .executemany ('SELECT ...'), it could be a cursor implementation which does .nextset () implicit, thus imitating a single result set. Or an implementation of .executemany () which does an .execute ('SELECT ..') with the next parameter set on a .nextset (). This example code helps both driver implementors and driver users. - it gives a structure to the driver documentation, as the writer would have to fill in the details for each implementation specific feature. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From Kamlesh.Vazirani@jwt.com Wed Mar 21 11:28:36 2001 From: Kamlesh.Vazirani@jwt.com (Kamlesh.Vazirani@jwt.com) Date: Wed, 21 Mar 2001 16:58:36 +0530 Subject: [DB-SIG] DCOracle Error Message-ID: Connecting to Oracle database Using DCOracle python package gives following error message,Pls help Import DCOracle (gives error message) File c:\pyhton20\pythonwin\DCOracle\__init__.py import sys,Buffer ImportError : DLL load failed:one of the library file needed to run this application cannot be found. My email_id : kjv@cheerful.com Regds Kamy From mal@lemburg.com Wed Mar 21 12:02:18 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 21 Mar 2001 13:02:18 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications) References: Message-ID: <3AB8984A.2C29799@lemburg.com> "Dittmar, Daniel" wrote: > > > Like I said before, using .executemany() with SELECT is not > > a good practice. > > Agreed in principle. Of course there are rare exceptions. > > > You lose too much control over what the > > DB does with the selects and errors will be not contain enough > > information to allow you to pinpoint the SELECT parameter > > set which failed. > > > > .executemany() was intended to be used with INSERT and UPDATE > > where many DBs offer array processing to speed up the process. > > Array INSERT and UPDATE have their problems too with regard to portability. > When one parameter set fails, what should be the outcome > - failure of the whole command? > - execute succeeds up to the offending parameters? > - should this be different for 'autocommit'? > > I guess each database will have one of these as the 'natural' > implementation. Each database will have a hard time to implement the other > one, possibly at the cost of not using the native capabilities, thus defying > the whole purpose of array commands. This is database defined. I guess most databases simply stop with the execution in case an INSERT fails and leave the database in a half-changed state. .rollback() then is the right thing to do. The DB API spec should have a note about this though, since is could cause data damage. > > For the SELECT case, please stick with separate calls to .execute(). > > Performance is really a non-issue here and keeping the SELECTs > > separated helps a lot in debugging code and making the overall > > experience clearer to the reader of the source code. > > > > This is advice for those using the DB standard, not those implementing it. True. > > If you really have to use SELECTs in .executemany() then the > > current definition of .nextset() will allow you to switch > > to the next result set in the queue, so you can still get > > at the different result sets. > > The point was: should the use of .nextset () be mandatory or is the > driver/database allowed to put everything into one result set. Yes, please make .nextset() mandatory. We will need to clarify this in the DB API spec. (still waiting for those patches ;-) > > It does not make any sense to > > return the union of the result sets (since the same could be > > achieved with a single SELECT and multiple WHERE conditio > > But array parameters allow you to prepare it once and execute it with a > variable number of input parameters. If you use the statement caching mechanism proposed in the DB API spec then you won't lose any performance due to having to re-prepare the command every time. > What I would suggest: > > Add a chapter 'Implementation defined features' to the standard. > - this would allow to be specific about being non specific > - that's a place to add example code which would implement a specific > behaviour. For the .executemany ('SELECT ...'), it could be a cursor > implementation which does .nextset () implicit, thus imitating a single > result set. Or an implementation of .executemany () which does an .execute > ('SELECT ..') with the next parameter set on a .nextset (). This example > code helps both driver implementors and driver users. > - it gives a structure to the driver documentation, as the writer would have > to fill in the details for each implementation specific feature. Good idea. Would you be willing to write up a starter ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From daniel.dittmar@sap.com Wed Mar 21 13:13:17 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Wed, 21 Mar 2001 14:13:17 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) Message-ID: > > The point was: should the use of .nextset () be mandatory or is the > > driver/database allowed to put everything into one result set. > > Yes, please make .nextset() mandatory. We will need to clarify this > in the DB API spec. (still waiting for those patches ;-) Just want to state my formal protest against this (mainly because I would have to treat INSERT/UPDATE/DELETE different from SELECT *before* executing, something I avoided so far). > > What I would suggest: > > > > Add a chapter 'Implementation defined features' to the standard. > > - this would allow to be specific about being non specific > > - that's a place to add example code which would implement > a specific > > behaviour. For the .executemany ('SELECT ...'), it could be a cursor > > implementation which does .nextset () implicit, thus > imitating a single > > result set. Or an implementation of .executemany () which > does an .execute > > ('SELECT ..') with the next parameter set on a .nextset (). > This example > > code helps both driver implementors and driver users. > > - it gives a structure to the driver documentation, as the > writer would have > > to fill in the details for each implementation specific feature. > > Good idea. Would you be willing to write up a starter ? OK, I'll try. Being fairly new to the DB API, I would appreciate if those with more experience could send me some topics that were portability issues in the past. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Wed Mar 21 13:26:12 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 21 Mar 2001 14:26:12 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications) References: Message-ID: <3AB8ABF4.62E38CED@lemburg.com> "Dittmar, Daniel" wrote: > > > > The point was: should the use of .nextset () be mandatory or is the > > > driver/database allowed to put everything into one result set. > > > > Yes, please make .nextset() mandatory. We will need to clarify this > > in the DB API spec. (still waiting for those patches ;-) > > Just want to state my formal protest against this (mainly because I would > have to treat INSERT/UPDATE/DELETE different from SELECT *before* executing, > something I avoided so far). It is really the only way to deal with this problem. Also, putting all rows into one result set doesn't really make sense, because in that case you could just as well use .execute() and a SELECT with multiple WHERE conditions or a UNION of SELECTS. An alternative would be outruling the use of SELECT with .executemany() in the DB API spec altogether and declaring the interface behaviour an implementation detail. > > > What I would suggest: > > > > > > Add a chapter 'Implementation defined features' to the standard. > > > - this would allow to be specific about being non specific > > > - that's a place to add example code which would implement > > a specific > > > behaviour. For the .executemany ('SELECT ...'), it could be a cursor > > > implementation which does .nextset () implicit, thus > > imitating a single > > > result set. Or an implementation of .executemany () which > > does an .execute > > > ('SELECT ..') with the next parameter set on a .nextset (). > > This example > > > code helps both driver implementors and driver users. > > > - it gives a structure to the driver documentation, as the > > writer would have > > > to fill in the details for each implementation specific feature. > > > > Good idea. Would you be willing to write up a starter ? > > OK, I'll try. Being fairly new to the DB API, I would appreciate if those > with more experience could send me some topics that were portability issues > in the past. Great :-) Here's a list: - transaction behaviour (implicit start of transactions when creating a cursor, implicit rollback when cursor is closed) - handling of multiple result returns using .nextset() - handling of SELECT with .executemany() - how to treat special database data types such as decimals and file column bindings -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From fog@mixadlive.com Wed Mar 21 13:39:29 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Wed, 21 Mar 2001 14:39:29 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifica tions) In-Reply-To: ; from daniel.dittmar@sap.com on Wed, Mar 21, 2001 at 02:13:17PM +0100 References: Message-ID: <20010321143929.A2878@developers.mixadlive.com> Scavenging the mail folder uncovered Dittmar, Daniel's letter: > > > > The point was: should the use of .nextset () be mandatory or is the > > > driver/database allowed to put everything into one result set. > > > > Yes, please make .nextset() mandatory. We will need to clarify this > > in the DB API spec. (still waiting for those patches ;-) > > Just want to state my formal protest against this (mainly because I would > have to treat INSERT/UPDATE/DELETE different from SELECT *before* executing, > something I avoided so far). i almost finished to write those little adjustments and clarifications we talked about. i was waiting for this discussion to finish before sendig the patch to this ml (the new html document accompained by a diff is enough?) i propose to: 1/ discuss a little bit on the "form" of the trivial arguments (english is not my native language) like cursor isolation, and then incorporate them as DBAPI-2.0 (nothing really changes from the old api) 2/ discuss a little bit more on "hot" stuff like executemany() (see formal protest above) and then write a revised dbapi (2.1?) i am quite new to this list, so i have a question: how was the dbapi document produced? how does the sig decide on controversial arguments like executemany()? expect the patches for tomorrow morning CET, ciao, federico From fog@mixadlive.com Wed Mar 21 13:45:06 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Wed, 21 Mar 2001 14:45:06 +0100 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications) In-Reply-To: <3AB8ABF4.62E38CED@lemburg.com>; from mal@lemburg.com on Wed, Mar 21, 2001 at 02:26:12PM +0100 References: <3AB8ABF4.62E38CED@lemburg.com> Message-ID: <20010321144506.B2878@developers.mixadlive.com> Scavenging the mail folder uncovered M.-A. Lemburg's letter: > Here's a list: > - transaction behaviour (implicit start of transactions when creating > a cursor, implicit rollback when cursor is closed) er... em... no. in a previous mail you said that cursors are not transaction-aware. this is very similar to the per-cursor commit extension implemented (and outruled by the dbapi) by psycopg, popy and maybe other drivers. > - handling of multiple result returns using .nextset() > - handling of SELECT with .executemany() ok, we are discussin it. > - how to treat special database data types such as decimals > and file column bindings i have some ideas on how to implement type-casting from db types to python types and classes. psycopg impelemnts two module functions (new_type() and register_type()) that can be used to register a new singleton type object (just like STRING, NUMBER, etc...) and let the driver use it to typecast from the db. the default types (STRING, etc...) are just created using those functiuons at module loading time. if you are interested i can write some lines about that or you can donload psycopg sources and look for the types_test.py script. ciao, federico From bzimmer@ziclix.com Wed Mar 21 14:55:14 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Wed, 21 Mar 2001 08:55:14 -0600 Subject: executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications) In-Reply-To: <20010321144506.B2878@developers.mixadlive.com> References: <3AB8ABF4.62E38CED@lemburg.com> <3AB8ABF4.62E38CED@lemburg.com> Message-ID: <5.0.2.1.0.20010321083752.00aa4488@ziclix.com> At 02:45 PM 3/21/2001 +0100, Federico Di Gregorio wrote: >Scavenging the mail folder uncovered M.-A. Lemburg's letter: > > Here's a list: > > - transaction behaviour (implicit start of transactions when creating > > a cursor, implicit rollback when cursor is closed) > >er... em... no. in a previous mail you said that cursors >are not transaction-aware. this is very similar to the per-cursor >commit extension implemented (and outruled by the dbapi) by >psycopg, popy and maybe other drivers. > > > - handling of multiple result returns using .nextset() > > - handling of SELECT with .executemany() Just so I'm clear, .executemany() with SELECT will result in many .nextset() calls. I don't want to have to parse SQL to figure out as an implementor if the call should be allowed. >ok, we are discussin it. > > > - how to treat special database data types such as decimals > > and file column bindings > >i have some ideas on how to implement type-casting from db types >to python types and classes. psycopg impelemnts two module functions >(new_type() and register_type()) that can be used to register a new >singleton type object (just like STRING, NUMBER, etc...) and let >the driver use it to typecast from the db. the default types (STRING, >etc...) are just created using those functiuons at module loading >time. if you are interested i can write some lines about that or you >can donload psycopg sources and look for the types_test.py script. I work with primarily with Informix, which has a couple of types not currently defined, such as Interval. To handle these cases I added the following to .execute*() and callproc(): c.execute("insert into yy (id, game_interval) values (?, ?)", [(8, interval)], bindings={1:INTERVAL}) - where bindings is a dict of key=? index and value=integer type code as defined in JDBC, ODBC and optionally the vendor I am a little confused by the setinputsizes functionality and seems a lot of "compliant" modules just pass on it. If one could advise on it's most common use I'd appreciate it. I use the following Java interface internally to take the value of the bindings and pass it to a more vendor-specific implementation: public PyObject getPyObject(ResultSet set, int col, int type) throws SQLException; public void setJDBCObject(PreparedStatement stmt, int index, PyObject object) throws SQLException; public void setJDBCObject(PreparedStatement stmt, int index, PyObject object, int type) throws SQLException; public void preExecute(Statement stmt) throws SQLException; public void postExecute(Statement stmt) throws SQLException; Then I allow every cursor to add arbitrary DataHandler's to handle special cases such as these for both inserts/updates and queries. I've found it to work quite well and allows the maximum amount of control for different database engines. For instance, it allows me to write code to handle getting the last Informix serial or MySql auto_increment without having to write a ton of custom code in the core of zxJDBC. By allowing the plugging in of DataHandler's all behaviour for type casting can be controlled by the end user if they so desire. Of course, by default, I handle every case I'm originally aware of and the DataHandler can be implemented in Java or Python. Another area where DataHandler's have helped tremendously is with CLOB and BLOB columns. I've had a hard time adding support for CLOBs to Informix, Oracle and MySql in any kind of uniform way. I used the DataHandler abstraction to get it work for each vendor (note: my implementation is fairly weak because I treat them more as big byte arrays than truly being CLOBs with locators and all, but the whole point of the DataHandler is to allow someone to change this behaviour for their needs without needing me to do it.) I don't know if you find any of this interesting or if it warrants discussion, but being able to handle all the different varieties of vendors with a single abstract code base required it and it has given me a really strong cross-vendor implementation, as it's been reported to me by end users that zxJDBC has worked out of the box with a number of different vendors. thanks, brian From akuchlin@mems-exchange.org Wed Mar 21 19:07:13 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Wed, 21 Mar 2001 14:07:13 -0500 Subject: [DB-SIG] PEP version of DB-API Message-ID: Python Enhancement Proposals (PEPs) with an 'Informational' status can be used to document Python-related standards. I'd like to get the DB-API into the PEPs. Marc-Andre, I vaguely remember that you were the primary editor of the spec; is it OK with you if I edit it into PEP form and put you down as the author? One question: should the 1.0 version of the API be turned into a spec for historical completeness? I vote -1; it's not that important and most (all?) modules follow 2.0 anyway. --amk From fog@mixadlive.com Thu Mar 22 10:08:23 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Thu, 22 Mar 2001 11:08:23 +0100 Subject: [DB-SIG] First patch to DBAPI Message-ID: <20010322110823.A703@mixadlive.com> --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline here is the first little patch to the dbapi document. note that i don't have included the changes on .executemany() because the discussion is not finished. in particular the following paragraph from the current document seems to go *agains* the ".executemany() produces multiple result sets" argument. Modules are free to implement this method using multiple calls to the execute() method or by using array operations to have the database process the ^^^^^^^^^^^^^^^^ sequence as a whole in one call. ^^^^^^^^^^ it is a big change and i'll wait fora *group* decision before sending a patch. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org A short story: I want you. I love you. I'll miss you. -- Me --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="DatabaseAPI-2.0.html.diff" --- DatabaseAPI-2.0.html Fri Feb 23 12:09:39 2001 +++ DatabaseAPI-2.1.html Mon Mar 19 19:24:38 2001 @@ -362,7 +362,9 @@ forward; an Error (or subclass) exception will be raised if any operation is attempted with the connection. The same applies to all cursor objects trying - to use the connection. + to use the connection. Note that closing a connection without + committing the changes first will cause an implicit + rollback to be performed.

commit() @@ -408,7 +410,13 @@

These objects represent a database cursor, which is used to - manage the context of a fetch operation. + manage the context of a fetch operation. Cursors created from + the same connection are not isolated, i.e., any changes + done to the database by a cursor are immediately visible by the + other cursors. Cursors created from different connections can + or can not be isolated, depending on how the transaction support + is implemented (see also the connection's rollback() + and commit() methods.)

Cursor Objects should respond to the following methods and attributes: @@ -421,10 +429,15 @@ This read-only attribute is a sequence of 7-item sequences. Each of these sequences contains information describing one result column: (name, type_code, display_size, - internal_size, precision, scale, null_ok). This - attribute will be None for operations that do not - return rows or if the cursor has not had an operation invoked - via the executeXXX() method yet. + internal_size, precision, scale, null_ok). The first + two items (name and type_code) are + mandatory, the other five are optional and must be set to + None if meaningfull values are not provided. +

+ This + attribute will be None for operations that do not + return rows or if the cursor has not had an operation invoked + via the executeXXX() method yet.

The type_code can be interpreted by comparing it to the Type Objects --PEIAKu/WMn1b1Hv9-- From mal@lemburg.com Thu Mar 22 10:42:46 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 22 Mar 2001 11:42:46 +0100 Subject: [DB-SIG] PEP version of DB-API References: Message-ID: <3AB9D726.C432E16@lemburg.com> Andrew Kuchling wrote: > > Python Enhancement Proposals (PEPs) with an 'Informational' status can > be used to document Python-related standards. I'd like to get the > DB-API into the PEPs. Good idea. > Marc-Andre, I vaguely remember that you were > the primary editor of the spec; is it OK with you if I edit it into > PEP form and put you down as the author? I'm not the only author... there are at least two others (Greg Stein and someone else from eShop who's name I don't remember). Anyway, the spec is in the public domain, so it should be no problem. > One question: should the 1.0 version of the API be turned into a spec > for historical completeness? I vote -1; it's not that important and > most (all?) modules follow 2.0 anyway. Hmm, there are clear differences between 1.0 and 2.0. Maybe you should at least a URL to the 2.0 version pointing to the 1.0 document. Having 1.0 in PEP form would have an educational value since, AFAIK, the DB API spec was the first specification written for Python which does not target the Python core itself. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Mar 22 10:48:07 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 22 Mar 2001 11:48:07 +0100 Subject: [DB-SIG] PEP version of DB-API References: Message-ID: <3AB9D867.F6C804C8@lemburg.com> One other issue: the DB API spec will have to have an editor to keep it in a sane state and prevent too much convolution to pile up. For the 1.0 -> 2.0 cycle this has helped much in keeping obscure features out of the spec. I suspect the next revision to have a need for such action too ;-) The general guideline for the DB API is to keep it flexible enough for interface authors to add their own extensions and OTOH to not make it too complicated for the authors to follow it (i.e. it shouldn't prevent authors from starting to code interfaces). Also, it has to assure that even low-tech databases can be DB API compliant to a certain degree. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From fog@mixadlive.com Thu Mar 22 11:05:42 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Thu, 22 Mar 2001 12:05:42 +0100 Subject: [DB-SIG] PEP version of DB-API In-Reply-To: <3AB9D867.F6C804C8@lemburg.com>; from mal@lemburg.com on Thu, Mar 22, 2001 at 11:48:07AM +0100 References: <3AB9D867.F6C804C8@lemburg.com> Message-ID: <20010322120542.B703@mixadlive.com> Scavenging the mail folder uncovered M.-A. Lemburg's letter: > The general guideline for the DB API is to keep it flexible enough > for interface authors to add their own extensions and OTOH to not > make it too complicated for the authors to follow it (i.e. it shouldn't > prevent authors from starting to code interfaces). Also, it has > to assure that even low-tech databases can be DB API compliant to > a certain degree. i completely agree. i much welcomed addition to the dbapi would be (as someone else said) the "formalization" of the parts that are left to the author. lets keep extensions to the api *well separated* from the api itself. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Best friends are often failed lovers. -- Me From mal@lemburg.com Thu Mar 22 22:52:46 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 22 Mar 2001 23:52:46 +0100 Subject: [DB-SIG] PEP version of DB-API References: <3AB9D867.F6C804C8@lemburg.com> <20010322120542.B703@mixadlive.com> Message-ID: <3ABA823E.23FA8AF0@lemburg.com> Federico Di Gregorio wrote: > > Scavenging the mail folder uncovered M.-A. Lemburg's letter: > > > The general guideline for the DB API is to keep it flexible enough > > for interface authors to add their own extensions and OTOH to not > > make it too complicated for the authors to follow it (i.e. it shouldn't > > prevent authors from starting to code interfaces). Also, it has > > to assure that even low-tech databases can be DB API compliant to > > a certain degree. > > i completely agree. i much welcomed addition to the dbapi would be > (as someone else said) the "formalization" of the parts that are > left to the author. lets keep extensions to the api *well separated* > from the api itself. Right. BTW, instead of applying your patches to the HTML page now, wouldn't it be better to rework the patches into a patch against the PEP version which Andrew wants to prepare ? (Note that PEPs are under CVS control, so we'll have a nice history record of what changed between versions and why.) -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Mar 22 22:58:57 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 22 Mar 2001 23:58:57 +0100 Subject: [DB-SIG] First patch to DBAPI References: <20010322110823.A703@mixadlive.com> Message-ID: <3ABA83B1.3412300B@lemburg.com> Federico Di Gregorio wrote: > > here is the first little patch to the dbapi document. The patch looks fine. > note that i > don't have included the changes on .executemany() because the discussion > is not finished. in particular the following paragraph from the > current document seems to go *agains* the ".executemany() produces > multiple result sets" argument. > > Modules are free to implement this method using multiple > calls to the execute() method or by using > array operations to have the database process the > ^^^^^^^^^^^^^^^^ > sequence as a whole in one call. > ^^^^^^^^^^ This refers to the use of .executemany() for INSERT and UPDATE operations which do not return any result sets. Back when we introduced the API we never even thought of using it for SELECT and multiple result sets. I think we should simply clarify that using SELECTs with .executemany() is explicitly left undefined by the DB API spec and that using the API for SELECTs will result in non-portable code. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Thu Mar 22 23:12:45 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Mar 2001 00:12:45 +0100 Subject: [DB-SIG] Re: column type casting References: <3AB8ABF4.62E38CED@lemburg.com> <3AB8ABF4.62E38CED@lemburg.com> <5.0.2.1.0.20010321083752.00aa4488@ziclix.com> Message-ID: <3ABA86ED.E2CEF221@lemburg.com> brian zimmer wrote: > > > > - how to treat special database data types such as decimals > > > and file column bindings > > > >i have some ideas on how to implement type-casting from db types > >to python types and classes. psycopg impelemnts two module functions > >(new_type() and register_type()) that can be used to register a new > >singleton type object (just like STRING, NUMBER, etc...) and let > >the driver use it to typecast from the db. the default types (STRING, > >etc...) are just created using those functiuons at module loading > >time. if you are interested i can write some lines about that or you > >can donload psycopg sources and look for the types_test.py script. > > I work with primarily with Informix, which has a couple of types not > currently defined, such as Interval. To handle these cases I added the > following to .execute*() and callproc(): > > c.execute("insert into yy (id, game_interval) values (?, ?)", [(8, > interval)], bindings={1:INTERVAL}) > > - where bindings is a dict of key=? index and value=integer type code as > defined in JDBC, ODBC and optionally the vendor I have similar code in mxODBC for this: I use a special converter function which can be registered on a per-cursor basis and which allows manipulating the fetch operations. I am not too satisfied with the interface though... perhaps we ought to try to define some standard DB API extension or at least a guideline as to how this sort of thing should be handled ?! > I am a little confused by the setinputsizes functionality and seems a lot > of "compliant" modules just pass on it. If one could advise on it's most > common use I'd appreciate it. > > I use the following Java interface internally to take the value of the > bindings and pass it to a more vendor-specific implementation: > > public PyObject getPyObject(ResultSet set, int col, int type) throws > SQLException; > public void setJDBCObject(PreparedStatement stmt, int index, PyObject > object) throws SQLException; > public void setJDBCObject(PreparedStatement stmt, int index, PyObject > object, int type) throws SQLException; > public void preExecute(Statement stmt) throws SQLException; > public void postExecute(Statement stmt) throws SQLException; > > Then I allow every cursor to add arbitrary DataHandler's to handle special > cases such as these for both inserts/updates and queries. I've found it to > work quite well and allows the maximum amount of control for different > database engines. For instance, it allows me to write code to handle > getting the last Informix serial or MySql auto_increment without having to > write a ton of custom code in the core of zxJDBC. By allowing the plugging > in of DataHandler's all behaviour for type casting can be controlled by the > end user if they so desire. Of course, by default, I handle every case I'm > originally aware of and the DataHandler can be implemented in Java or Python. > > Another area where DataHandler's have helped tremendously is with CLOB and > BLOB columns. I've had a hard time adding support for CLOBs to Informix, > Oracle and MySql in any kind of uniform way. I used the DataHandler > abstraction to get it work for each vendor (note: my implementation is > fairly weak because I treat them more as big byte arrays than truly being > CLOBs with locators and all, but the whole point of the DataHandler is to > allow someone to change this behaviour for their needs without needing me > to do it.) > > I don't know if you find any of this interesting or if it warrants > discussion, but being able to handle all the different varieties of vendors > with a single abstract code base required it and it has given me a really > strong cross-vendor implementation, as it's been reported to me by end > users that zxJDBC has worked out of the box with a number of different vendors. Data handlers are one way to do this. In mxODBC I chose the positional approach for the converter function. Still missing is some sort of generic data input/output handler device. I remember that Andy's MySQL module has a nice way to this -- it's easy for him though, because most of his code is in Python which is simple to extend by subclassing. One way to implement this would be by using callbacks which are triggered by certain type mappings. They are cumbersome to use though... -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From fog@mixadlive.com Sat Mar 24 01:33:16 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Sat, 24 Mar 2001 02:33:16 +0100 Subject: [DB-SIG] PEP version of DB-API In-Reply-To: <3ABA823E.23FA8AF0@lemburg.com>; from mal@lemburg.com on Thu, Mar 22, 2001 at 11:52:46PM +0100 References: <3AB9D867.F6C804C8@lemburg.com> <20010322120542.B703@mixadlive.com> <3ABA823E.23FA8AF0@lemburg.com> Message-ID: <20010324023316.B32332@dana.initd.org> Scavenging the mail folder uncovered M.-A. Lemburg's letter: > BTW, instead of applying your patches to the HTML page now, > wouldn't it be better to rework the patches into a patch > against the PEP version which Andrew wants to prepare ? (Note > that PEPs are under CVS control, so we'll have a nice history > record of what changed between versions and why.) sure. using cvs for all our development i can't be happiest... :) -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From fog@mixadlive.com Sat Mar 24 01:34:48 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Sat, 24 Mar 2001 02:34:48 +0100 Subject: [DB-SIG] First patch to DBAPI In-Reply-To: <3ABA83B1.3412300B@lemburg.com>; from mal@lemburg.com on Thu, Mar 22, 2001 at 11:58:57PM +0100 References: <20010322110823.A703@mixadlive.com> <3ABA83B1.3412300B@lemburg.com> Message-ID: <20010324023448.C32332@dana.initd.org> Scavenging the mail folder uncovered M.-A. Lemburg's letter: > Federico Di Gregorio wrote: > > Modules are free to implement this method using multiple > > calls to the execute() method or by using > > array operations to have the database process the > > ^^^^^^^^^^^^^^^^ > > sequence as a whole in one call. > > ^^^^^^^^^^ > > This refers to the use of .executemany() for INSERT and UPDATE > operations which do not return any result sets. Back when we > introduced the API we never even thought of using it for SELECT > and multiple result sets. ah, ok. > I think we should simply clarify that using SELECTs with > .executemany() is explicitly left undefined by the DB API spec and > that using the API for SELECTs will result in non-portable code. i agree. if nobody has something to add to this topic i'll add this one to the next set of patches. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org God is real. Unless declared integer. -- Anonymous FORTRAN programmer From daniel.dittmar@sap.com Fri Mar 23 09:32:10 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 23 Mar 2001 10:32:10 +0100 Subject: [DB-SIG] RE: column type casting Message-ID: > Data handlers are one way to do this. In mxODBC I chose the positional > approach for the converter function. Still missing is some sort > of generic data input/output handler device. I remember that > Andy's MySQL > module has a nice way to this -- it's easy for him though, because > most of his code is in Python which is simple to extend by > subclassing. > > One way to implement this would be by using callbacks which are > triggered by certain type mappings. They are cumbersome to use > though... In sapdbapi, you can - install data handler for each column of a cursor - use the connection to specify data handlers for specific types which are then used for every cursor In addition, there are some default handler for date/time types: conversion from the internal format to either tuples or to strings using a time.strftime format. Yet another thing we could standardize on (although maybe we should ask a few users what they found useful). Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From bzimmer@ziclix.com Fri Mar 23 12:35:32 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Fri, 23 Mar 2001 06:35:32 -0600 Subject: [DB-SIG] RE: column type casting In-Reply-To: Message-ID: Daniel, What's the API like for your datahandlers? Are they written in C or Python? Should we collect a couple examples and present them in the PEP? In addition to being able to handle different data types, the functionality might want to include events/callbacks for the lifecycle of the executions. As I stated, this is useful for collecting the auto increment values for certain columns and isn't so much the morphing of data. brian > > Data handlers are one way to do this. In mxODBC I chose the positional > > approach for the converter function. Still missing is some sort > > of generic data input/output handler device. I remember that > > Andy's MySQL > > module has a nice way to this -- it's easy for him though, because > > most of his code is in Python which is simple to extend by > > subclassing. > > > > One way to implement this would be by using callbacks which are > > triggered by certain type mappings. They are cumbersome to use > > though... > > In sapdbapi, you can > - install data handler for each column of a cursor > - use the connection to specify data handlers for specific types which are > then used for every cursor > > In addition, there are some default handler for date/time types: conversion > from the internal format to either tuples or to strings using > a time.strftime format. > > Yet another thing we could standardize on (although maybe we should ask a > few users what they found useful). > > Daniel > > -- > Daniel Dittmar > daniel.dittmar@sap.com > SAP DB, SAP Labs Berlin > http://www.sapdb.org/ > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From daniel.dittmar@sap.com Fri Mar 23 13:49:53 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 23 Mar 2001 14:49:53 +0100 Subject: [DB-SIG] column type casting Message-ID: > What's the API like for your datahandlers? Are they written > in C or Python? Should we collect a couple examples and present them > in the PEP? The datahandler are Callable Objects (they are supposed to be written by the application programmer) I supply example handler for the conversion of SAP DB date values to more pythonic values # returns a tuple (year, month, day) def dateTuple (sapdbDate): if sapdbDate is None: return None return int (sapdbDate[:4]), int (sapdbDate[4:6]), int (sapdbDate[6:]) # returns a float as used by the time module def dateVal (sapdbDate): if sapdbDate is None: return None year, month, day = dateTuple (sapdbDate) return time.mktime (year, month, day, -1, -1, -1, -1, -1, -1,) # allows to translate using strftime format strings class AbstractTimeFormat: def __init__ (self, fmt): self.fmt = fmt def __call__ (self, sapdbString): if sapdbString is None: return None localtime = time.localtime ( self.toTime(sapdbString)) return time.strftime (self.fmt, localtime) class DateFormat (AbstractTimeFormat): def toTime (self, sapdbDate): return dateVal (sapdbDate) The handlers can be installed in several ways: - specific to a cursor: cursor.setTranslation ([None, dateTuple, DateFormat ('%Y')]) the parameter array has one handler per output column, Nones are ignored - specific to types: cursor.setTypeTranslation ({'Date': dateTuple, 'Time': timeTuple}) this will install the handler for each column with a specific type (I'm using SAP DB specific type keys, as I need to distinguish between Date, Time and Timestamp) - you can call connection.setTypeTranslation, this will install the handler for every newly created cursor. There are ready made dictionaries tupleTranslation = { 'Date': dateTuple, 'Time': timeTuple, 'Timestamp': timestampTuple, } so someone could simply write connection.setTypeTranslation (sapdbapi.tupleTranslation) and forget afterwards about date/time conversions. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Fri Mar 23 15:39:35 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Mar 2001 16:39:35 +0100 Subject: [DB-SIG] RE: column type casting References: Message-ID: <3ABB6E37.DA72905D@lemburg.com> brian zimmer wrote: > > Daniel, > > What's the API like for your datahandlers? Are they written in C or Python? Should we collect a couple examples and present them > in the PEP? > > In addition to being able to handle different data types, the functionality might want to include events/callbacks for the lifecycle > of the executions. As I stated, this is useful for collecting the auto increment values for certain columns and isn't so much the > morphing of data. Good idea. There seem to be a few things common to all implementations: * settings are inherited from connection to cursor objects, but can be overridden on the cursor * argument callback assignment is done in a positional way, meaning that each argument can be handled individually * type mappings map cursor.description type codes to converters Perhaps we could agree on a common standard for these DB API extensions and then add them as special DB API extension guideline to the spec ?! -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From fog@mixadlive.com Fri Mar 23 17:45:13 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Fri, 23 Mar 2001 18:45:13 +0100 Subject: [DB-SIG] RE: column type casting In-Reply-To: <3ABB6E37.DA72905D@lemburg.com>; from mal@lemburg.com on Fri, Mar 23, 2001 at 04:39:35PM +0100 References: <3ABB6E37.DA72905D@lemburg.com> Message-ID: <20010323184513.B2408@mixadlive.com> Scavenging the mail folder uncovered M.-A. Lemburg's letter: [snip] > Good idea. > > There seem to be a few things common to all implementations: > > * settings are inherited from connection to cursor objects, but > can be overridden on the cursor > > * argument callback assignment is done in a positional way, meaning > that each argument can be handled individually > > * type mappings map cursor.description type codes to converters the last two items are quite orthogonal, but the basic concept, the use of a typecast object or a callback function applies to both. this is why i propose the following api that, to me, has some advantages: 1/ it is simple (both to use and implement) 2/ it is db-independent 3/ imho, does it the python-way... first of all, the callbacks are callable objects and the old type singletons should be implemented as those new objects (everything that applies to the old singleton types applies to this new type objects.) you can build a new type object by calling the new_type() function on the module: TYPE = module.new_type(name, cast_func, type_codes) where name is just a string (we can drop it, it is usefull only for debugging purpouses); cast_func is a function that takes a data in the db _natural_ format (that is a String or Buffer, usually) and casts it into the new type and type codes are the codes from description.type_code to which the TYPE object should be equal. mmm, bad english, example: TYPE == cursor.fetchone().description[1] should be true is the type code returned by the db is one of the values in type_codes. as i said above, TYPE should be a callable object (it works like a callback function) so that doing TYPE(data...) returns the data correctly type-casted. now that we have types, we can use them in two, orthoganl ways. we can register the types with the system (i'll put the function in module, because the default types NUMBER, STRING, etc. are defined in it, but working on the connection is equally valid) by calling: module.register_type(TYPE) from now on all the columns that have a type_code included in the TYPE's list of type_codes, are concerted by calling TYPE(data) on the column data returned by fetchXXX(). what happens if (like in postgres lobs) the type code is not enough but u need to convert just a single column? you simply call: cursor.register_type(TYPE, column) to associate the TYPE callback to a specific column in a specific cursor (i see aproblem here, what happens if the user forget to destroy the cursor and reuse it for a different SELECT? maybe the data can't be converted and an exception should be raised?) that's all. as you see, three functions and an object that is already half-implemented in the current driver. this stuff should be fairly easy to implement for everyone. and cover almost all cases. what do you think about? ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Those who do not study Lisp are doomed to reimplement it. Poorly. -- from Karl M. Hegbloom .signature From mal@lemburg.com Fri Mar 23 18:24:09 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 23 Mar 2001 19:24:09 +0100 Subject: [DB-SIG] RE: column type casting References: <3ABB6E37.DA72905D@lemburg.com> <20010323184513.B2408@mixadlive.com> Message-ID: <3ABB94C9.73A19800@lemburg.com> Federico Di Gregorio wrote: > > Scavenging the mail folder uncovered M.-A. Lemburg's letter: > [snip] > > Good idea. > > > > There seem to be a few things common to all implementations: > > > > * settings are inherited from connection to cursor objects, but > > can be overridden on the cursor > > > > * argument callback assignment is done in a positional way, meaning > > that each argument can be handled individually > > > > * type mappings map cursor.description type codes to converters > > the last two items are quite orthogonal, but the basic concept, the use > of a typecast object or a callback function applies to both. this is why > i propose the following api that, to me, has some advantages: > > 1/ it is simple (both to use and implement) > > 2/ it is db-independent > > 3/ imho, does it the python-way... > > first of all, the callbacks are callable objects and the old type > singletons should be implemented as those new objects (everything > that applies to the old singleton types applies to this new type > objects.) you can build a new type object by calling the new_type() > function on the module: > > TYPE = module.new_type(name, cast_func, type_codes) > > where name is just a string (we can drop it, it is usefull only for > debugging purpouses); cast_func is a function that takes a data in > the db _natural_ format (that is a String or Buffer, usually) and > casts it into the new type and type codes are the codes from > description.type_code to which the TYPE object should be equal. > mmm, bad english, example: TYPE == cursor.fetchone().description[1] > should be true is the type code returned by the db is one of the > values in type_codes. This is OK for data input, but how do you specify the case where you want database output to use a specific type object ? Note that you have a multiple to one mapping here, so the interface won't be able to map a specific type code to one well defined type constructor. Also, the data returned by the database may be very different from what you pass in on the input side at Python level, e.g. on input you may have Date(123456) with 123456 being a 1970 based ticks value, but the database generates 1900 based ticks values (OK, this is an extreme example, but you get the point...) ? > as i said above, TYPE should be a callable object (it works like a > callback function) so that doing TYPE(data...) returns the data > correctly type-casted. > > now that we have types, we can use them in two, orthoganl ways. > we can register the types with the system (i'll put the function > in module, because the default types NUMBER, STRING, etc. are > defined in it, but working on the connection is equally valid) > by calling: > > module.register_type(TYPE) > > from now on all the columns that have a type_code included in the > TYPE's list of type_codes, are concerted by calling TYPE(data) on > the column data returned by fetchXXX(). Make that connection.register_type(...) and cursor.register_type(...) with the cursor inheriting the type registrations from the connection. A module scope registration will only cause problems (thread-wise and design-wise too). > what happens if (like in postgres lobs) the type code is not enough > but u need to convert just a single column? you simply call: > > cursor.register_type(TYPE, column) > > to associate the TYPE callback to a specific column in a specific > cursor (i see aproblem here, what happens if the user forget to > destroy the cursor and reuse it for a different SELECT? maybe > the data can't be converted and an exception should be raised?) > > that's all. as you see, three functions and an object that is already > half-implemented in the current driver. this stuff should be fairly > easy to implement for everyone. and cover almost all cases. what > do you think about? > > ciao, > federico > > -- > Federico Di Gregorio > MIXAD LIVE Chief of Research & Technology fog@mixadlive.com > Debian GNU/Linux Developer & Italian Press Contact fog@debian.org > Those who do not study Lisp are doomed to reimplement it. Poorly. > -- from Karl M. Hegbloom .signature -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From fog@mixadlive.com Fri Mar 23 19:36:37 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Fri, 23 Mar 2001 20:36:37 +0100 Subject: [DB-SIG] RE: column type casting In-Reply-To: <3ABB94C9.73A19800@lemburg.com>; from mal@lemburg.com on Fri, Mar 23, 2001 at 07:24:09PM +0100 References: <3ABB6E37.DA72905D@lemburg.com> <20010323184513.B2408@mixadlive.com> <3ABB94C9.73A19800@lemburg.com> Message-ID: <20010323203637.C2408@mixadlive.com> Scavenging the mail folder uncovered M.-A. Lemburg's letter: [snip] > > mmm, bad english, example: TYPE == cursor.fetchone().description[1] > > should be true is the type code returned by the db is one of the > > values in type_codes. > > This is OK for data input, but how do you specify the case where > you want database output to use a specific type object ? em... i was not talking about data input at all. you tell the driver to use a specific object for database output by calling one of the register_type() functions, as explained below. maybe my english is worse than i think, coding example (using dbapi as the module name :) # this little demo show how to fetch some icons stored in the db # both as pnginame type and simple strings... import dbapi, Image, StringIO def makePngImage(s): return Image.open(StringIO(s)) o = dbapi.connect(DSN) c = o.cursor() # we do a select to obtain the type (name = '' select 0 rows, but # we are interested in the type_code, we don't want rows at now c.execute("SELECT icon FROM icons_table WHERE name = ''") type_code = c.description[0][1] # this register the type as a *generic* type caster for every select # on columns that have a type of code_type PNGIMAGE = .new_type("PNGIMAGE", makePngImage, (type_code,)) dbapi.register_type(PNGIMAGE) # puts in icons a series of Image object from the Image library c.execute("SELECT icon FROM icons_table WHERE name LIKE '%.png'") icons = c.fetchall() # now, what happens if the db does not support a different type # for images but just store them in a binary or string field? # we tell the cursor to apply the typecasting object to the column 1 # (in column 0 we put the icons names...) c.register_type(PNGIMAGE, 0) ic.execute("SELECT name, icon FROM icons_table WHERE name LIKE '%.png'") names_and_icons = c.fetchall() it is a little bit more clear now? note that the default STRING, DATETIME, NUMBER, etc. objects are created by the module at init time but are exactly the same and are registered *only* with the module, not with cursoer or connections. you can override them a module level or by registering your custom objects with the connections and cursors. > Note that you have a multiple to one mapping here, so the interface > won't be able to map a specific type code to one well defined > type constructor. Also, the data returned by the database may > be very different from what you pass in on the input side at > Python level, e.g. on input you may have Date(123456) with 123456 > being a 1970 based ticks value, but the database generates > 1900 based ticks values (OK, this is an extreme example, but you > get the point...) ? this confusion derives from the fact that you interpreted my type object as two-ways. they are one-way only, they only convert from the db to python. the old Date, Binary, etc, are still good to convert from python to the db. to make it clearer, BINARY (all uppercase) converts from the db to python and produce a python buffer, Binary convert from python to the db and what it produces is application dependent. [snip] > Make that connection.register_type(...) and cursor.register_type(...) > with the cursor inheriting the type registrations from the connection. > A module scope registration will only cause problems (thread-wise > and design-wise too). the module scope registration is there to allow you to override the default type casting object: STRING, DATETIME, etc... so we have: module.register_type(TYPE) - convert based on type_code connection.register_type(TYPE) - convert based on the type_code cursor.register_type(TYPE, column) - convert based on column i hope this clarifies my proposal a little bit, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From bzimmer@ziclix.com Mon Mar 26 13:55:00 2001 From: bzimmer@ziclix.com (brian zimmer) Date: Mon, 26 Mar 2001 07:55:00 -0600 Subject: [DB-SIG] RE: column type casting In-Reply-To: <20010323203637.C2408@mixadlive.com> Message-ID: > em... i was not talking about data input at all. you tell the driver > to use a specific object for database output by calling one of the > register_type() functions, as explained below. maybe my english > is worse than i think, coding example (using dbapi as the module name :) > We need to be able to specify handling for input and output. For instance, since Python has no boolean type and some databases do (at least Informix does), the enduser needs to be able to specify to the driver that the type should be mapped. This is also important for working with BLOBs and CLOBs so the user is free to use python files, strings, byte arrays, and the have the data properly converted. This holds true on the outbound as well. > > # this little demo show how to fetch some icons stored in the db > # both as pnginame type and simple strings... > > import dbapi, Image, StringIO > > def makePngImage(s): > return Image.open(StringIO(s)) > > o = dbapi.connect(DSN) > c = o.cursor() > > # we do a select to obtain the type (name = '' select 0 rows, but > # we are interested in the type_code, we don't want rows at now > c.execute("SELECT icon FROM icons_table WHERE name = ''") > type_code = c.description[0][1] > > # this register the type as a *generic* type caster for every select > # on columns that have a type of code_type > PNGIMAGE = .new_type("PNGIMAGE", makePngImage, (type_code,)) > dbapi.register_type(PNGIMAGE) > > # puts in icons a series of Image object from the Image library > c.execute("SELECT icon FROM icons_table WHERE name LIKE '%.png'") > icons = c.fetchall() > > # now, what happens if the db does not support a different type > # for images but just store them in a binary or string field? > # we tell the cursor to apply the typecasting object to the column 1 > # (in column 0 we put the icons names...) > c.register_type(PNGIMAGE, 0) > ic.execute("SELECT name, icon FROM icons_table WHERE name LIKE '%.png'") > names_and_icons = c.fetchall() > I presume this is a typo? Should it not read: c.register_type(PNGIMAGE, 1) since the icon is second in the select? > it is a little bit more clear now? note that the default STRING, DATETIME, > NUMBER, etc. objects are created by the module at init time but are > exactly the same and are registered *only* with the module, not with > cursoer or connections. you can override them a module level or by > registering your custom objects with the connections and cursors. > I like the idea of a single callable object as the converter so you can easily mix and match for datatypes, but it needs to go both ways. I'm also partial to my syntax: ic.execute("SELECT name, icon FROM icons_table WHERE name LIKE '%.png'", bindings={1, PNGIMAGE}) so the state can be maintained just during the call to execute. If you wish to keep it for all calls just pull the dictionary out and then include it with each call. > > Note that you have a multiple to one mapping here, so the interface > > won't be able to map a specific type code to one well defined > > type constructor. Also, the data returned by the database may > > be very different from what you pass in on the input side at > > Python level, e.g. on input you may have Date(123456) with 123456 > > being a 1970 based ticks value, but the database generates > > 1900 based ticks values (OK, this is an extreme example, but you > > get the point...) ? > > this confusion derives from the fact that you interpreted my type object > as two-ways. they are one-way only, they only convert from the db to > python. the old Date, Binary, etc, are still good to convert from python > to the db. to make it clearer, BINARY (all uppercase) converts from the > db to python and produce a python buffer, Binary convert from python to > the db and what it produces is application dependent. > Even if it's application dependent, why not have a consistent mechanism for converting? > [snip] > > Make that connection.register_type(...) and cursor.register_type(...) > > with the cursor inheriting the type registrations from the connection. > > A module scope registration will only cause problems (thread-wise > > and design-wise too). > > the module scope registration is there to allow you to override the > default type casting object: STRING, DATETIME, etc... so we have: > > module.register_type(TYPE) - convert based on type_code > connection.register_type(TYPE) - convert based on the type_code > cursor.register_type(TYPE, column) - convert based on column > I would also like to add support for cursor lifecycles. This is especially useful for me because the JDBC drivers for each vendor offer a number of very convenient methods that simplify work later, such as auto-incremented columns. Does this hold true for other technologies such as ODBC or native libraries? thanks, brian From evgenys@cs.bgu.ac.il Mon Mar 26 16:31:42 2001 From: evgenys@cs.bgu.ac.il (shusterman evgeny) Date: Mon, 26 Mar 2001 18:31:42 +0200 Subject: [DB-SIG] database api 2.0 Message-ID: <3ABF6EED.CE867F90@cs.bgu.ac.il> Hi , i am looking for documentasion about working with Python Databese API 2.0 and sources for it's downloading . If you can give me the where i could find it . Thanks . From daniel.dittmar@sap.com Mon Mar 26 14:59:04 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 26 Mar 2001 16:59:04 +0200 Subject: [DB-SIG] RE: column type casting Message-ID: > We need to be able to specify handling for input and output. agreed > I like the idea of a single callable object as the converter > so you can easily mix and match for datatypes, but it needs to go both > ways. How can it be a callable object if it goes both ways? Wouldn't it need two methods for db => python and python => db? I know that Python objects can have metthods in addition to being callable. But when there are symmetrical behaviours, it doesn't make sense to make of them the 'call'. > I'm also partial to my syntax: > ic.execute("SELECT name, icon FROM icons_table WHERE name > LIKE '%.png'", bindings={1, PNGIMAGE}) Not quite sure I like it, I'll see how it looks tomorrow. > > > A module scope registration will only cause problems (thread-wise > > > and design-wise too). I agree with Marc there. If someone wants to mess with module variables, he/she should do it in his own module. > > > > the module scope registration is there to allow you to override the > > default type casting object: STRING, DATETIME, etc... so we have: Understood, but not agreed > > module.register_type(TYPE) - convert based on type_code > > connection.register_type(TYPE) - convert based on the type_code > > cursor.register_type(TYPE, column) - convert based on column Wouldn't it be clearer for the cursor to have separate methods to register by type and to register by pos? How should a cursor behave when there is a new execute? - forget conversion information (fall back to connection default, fall back to default at cursor creation time) - keep conversion by type - keep conversion by position only if same command - make conversion a feature of the exact statement (if a statement cache is used) Another idea: conversions that span multiple columns - DATE + TIME combined into a timestamp - mime type in STRING + BLOB I think that this is too complex to be put into the standard, but how about a generic cursor wrapper which shows how to write these kinds of filters? Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From Nides" This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C0B642.346C8D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! I am attempting to connect to PoPy via Python.. However I don't think I = am making a connection. The following is the code that I am using to connect to PoPy in Python: import PoPy db =3D PoPy.connect('dbname=3Dsupplydb host=3Dthales port=3D5432 = user=3Ddavid') cr =3D db.cursor() cr.execute('::::whatever:::') ...Thats what I am doing. If you have any comments, or suggestions I = would highly appreciate them!!! Thank You, David Nides@mediaone.net ------=_NextPart_000_0022_01C0B642.346C8D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello!
 
I am attempting to connect to PoPy via = Python..=20 However I don't think I am making a connection.
 
The following is the code that I am = using to=20 connect to PoPy in Python:
 
import PoPy
 
db =3D PoPy.connect('dbname=3Dsupplydb = host=3Dthales=20 port=3D5432 user=3Ddavid')
 
cr =3D db.cursor()
cr.execute('::::whatever:::')
 
...Thats what I am doing. If you have = any comments,=20 or suggestions I would highly appreciate them!!!
 
Thank You,
 
David
 
Nides@mediaone.net
------=_NextPart_000_0022_01C0B642.346C8D80-- From chris@onca.catsden.net Tue Mar 27 04:19:47 2001 From: chris@onca.catsden.net (chris@onca.catsden.net) Date: Mon, 26 Mar 2001 20:19:47 -0800 (PST) Subject: [DB-SIG] Connecting to PoPy via Python In-Reply-To: <002501c0b674$7f395820$7701a8c0@compaq> Message-ID: On Mon, 26 Mar 2001, Nides wrote: > Hello! > > I am attempting to connect to PoPy via Python.. However I don't think I am making a connection. > > The following is the code that I am using to connect to PoPy in Python: > > import PoPy > > db = PoPy.connect('dbname=supplydb host=thales port=5432 user=david') > > cr = db.cursor() > cr.execute('::::whatever:::') > > ...Thats what I am doing. If you have any comments, or suggestions I would highly appreciate them!!! Not played with PoPy yet (been using PyGresSQL myself), but aren't you supposed to do something like this, instead: db = PoPy.connect( dbname='supplydb', host='thales', port=5432, user='david' ) The first way seems... very PHPish... eww :) ("`-/")_.-'"``-._ 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 corour01@motorola.com Tue Mar 27 18:49:44 2001 From: corour01@motorola.com (O'Rourke Clodagh-corour01) Date: Tue, 27 Mar 2001 19:49:44 +0100 Subject: [DB-SIG] Multiple Connections?? Message-ID: <13EE655665F4D311AB4D0008C789498A01EE2CA9@zei02exm02.cork.cig.mot.com> Hi All, I'm using the informixdb module with Python 1.5.2. In a function I connect to a db and after some sql close the connection. Then I called another function which creates a connection to the same db. However I am getting the following error InformixdbError: Error -27000 performing LOGON: Cannot support multiple connections over shared memory I have a connection.close() statement before calling the second function. Is there any other way to delete a connection. Or is the any way of debugging or monitoring all db connections. This error is driving me mad!!!!! Thanx Clodagh From dieter@sz-sb.de Wed Mar 28 07:19:21 2001 From: dieter@sz-sb.de (Dr. Dieter Maurer) Date: Wed, 28 Mar 2001 09:19:21 +0200 (CEST) Subject: [DB-SIG] Multiple Connections?? In-Reply-To: <13EE655665F4D311AB4D0008C789498A01EE2CA9@zei02exm02.cork.cig.mot.com> References: <13EE655665F4D311AB4D0008C789498A01EE2CA9@zei02exm02.cork.cig.mot.com> Message-ID: <15041.36722.269183.739630@dieter.sz-sb.de> O'Rourke Clodagh-corour01 writes: > I'm using the informixdb module with Python 1.5.2. In a function I connect to a db and after some sql close the connection. Then I called another function which creates a connection to the same db. However I am getting the following error > > InformixdbError: Error -27000 performing LOGON: Cannot support multiple connections over shared memory > > I have a connection.close() statement before calling the second function. Is there any other way to delete a connection. Or is the any way of debugging or monitoring all db connections. I have seen similar problems with DCOracle inside Zope. However, this is a very complex application and, probably, close is not called in this case. I cannot help you with the precise question. However, if you do not need a new connection, e.g. for a new login, you could use a connection cache instead of explicitly opening and closing the connection. Maybe, you can also work around the problem, by choosing a different connection type (as the error message suggests that multiple connections are supported unless they use "shared memory"). Dieter From markybob@markybob.com Wed Mar 28 20:41:51 2001 From: markybob@markybob.com (Mark Pinto) Date: Wed, 28 Mar 2001 14:41:51 -0600 Subject: [DB-SIG] tkinter/database interface Message-ID: <20010328144151.A4736@markybob.com> I have purchased 'Python and Tkinter programmin', in hopes to learn how to interface a Tkinter GUI with a PostgreSQL database. However, the book did not cover such things, but soley the creation of the GUI itself. Does anyone know of any GPL program whose source I could look at and learn how to do this? Or online documentation specific to GUI and databases? Mark Pinto From fog@mixadlive.com Thu Mar 29 13:43:43 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Thu, 29 Mar 2001 15:43:43 +0200 Subject: [DB-SIG] RE: column type casting In-Reply-To: ; from bzimmer@ziclix.com on Mon, Mar 26, 2001 at 07:55:00AM -0600 References: <20010323203637.C2408@mixadlive.com> Message-ID: <20010329154342.G705@mixadlive.com> sorry for being so late in the answer... Scavenging the mail folder uncovered brian zimmer's letter: > We need to be able to specify handling for input and output. agreed, but... i was talking about adapting the db api type, not about rewriting it from scratch. this is way i addressed the problem the way i did. note also that i am from keepend the two directions (db->python and python->db) quite separated, because this way is easies to cope with different dbs. [snip] > I presume this is a typo? Should it not read: > > c.register_type(PNGIMAGE, 1) > > since the icon is second in the select? yes, it is a typo. > > it is a little bit more clear now? note that the default STRING, DATETIME, > > NUMBER, etc. objects are created by the module at init time but are > > exactly the same and are registered *only* with the module, not with > > cursoer or connections. you can override them a module level or by > > registering your custom objects with the connections and cursors. > > > > I like the idea of a single callable object as the converter so you can easily mix and match for datatypes, but it needs to go both > ways. I'm also partial to my syntax: > > ic.execute("SELECT name, icon FROM icons_table WHERE name LIKE '%.png'", bindings={1, PNGIMAGE}) i *don't* like the idea of a single callable object. in the python-to-db conversion, the current objects (Date, Binary) work quite well. we only need to formalize what are the default, required types and what are left to the implementation. about your syntax, it has the advantage of being valid for just 1 execute() call. it is a nice addition to the proposted api and should work as .register_type() / .execute() / .unregister_type() or something similar. > so the state can be maintained just during the call to execute. If you wish to keep it for all calls just pull the dictionary out > and then include it with each call. i'd like to keep the register_type() stuff anyway. > > this confusion derives from the fact that you interpreted my type object > > as two-ways. they are one-way only, they only convert from the db to > > python. the old Date, Binary, etc, are still good to convert from python > > to the db. to make it clearer, BINARY (all uppercase) converts from the > > db to python and produce a python buffer, Binary convert from python to > > the db and what it produces is application dependent. > > > > Even if it's application dependent, why not have a consistent mechanism for converting? but *we have* a consistent mechanism for converting from python to db, it is explained in the db api... you just need to add more types and document them as an extension (String, Date, Time and Binary are really basic, maybe we can discuss about adding some more default types, or are the the common base already?) [snip] > I would also like to add support for cursor lifecycles. This is especially useful for me because the JDBC drivers for each vendor > offer a number of very convenient methods that simplify work later, such as auto-incremented columns. Does this hold true for other > technologies such as ODBC or native libraries? can you expand i little bit on that, i don't know what a "cursor lifecycle" is... Scavenging the mail folder uncovered Dittmar, Daniel's letter: > > > I like the idea of a single callable object as the converter > > so you can easily mix and match for datatypes, but it needs to go both > > ways. > > How can it be a callable object if it goes both ways? Wouldn't it need two > methods for db => python and python => db? I know that Python objects can > have metthods in addition to being callable. But when there are symmetrical > behaviours, it doesn't make sense to make of them the 'call'. this is another reason to keep the two directions separated, they are not perfectly symmetrical. > > > > A module scope registration will only cause problems (thread-wise > > > > and design-wise too). > > I agree with Marc there. If someone wants to mess with module variables, > he/she should do it in his own module. this one was just to keep the type singletons uniform. remember that in my propostal, the STRING, ROWID, etc. module variables are just pre-registered types. > > > the module scope registration is there to allow you to override the > > > default type casting object: STRING, DATETIME, etc... so we have: > > Understood, but not agreed ok ;) > > > module.register_type(TYPE) - convert based on type_code > > > connection.register_type(TYPE) - convert based on the type_code > > > cursor.register_type(TYPE, column) - convert based on column > > Wouldn't it be clearer for the cursor to have separate methods to register > by type and to register by pos? maybe yes. this was just a proof of concept. method names can be changed until we all agree on them. > How should a cursor behave when there is a new execute? > - forget conversion information (fall back to connection default, fall back > to default at cursor creation time) > - keep conversion by type conversion by type should be keeped, maybe even conversion by position, because you want to set the converion stuff once and then to many queries inside a loop, right? > Another idea: conversions that span multiple columns > - DATE + TIME combined into a timestamp > - mime type in STRING + BLOB hey, this is cool! stuff for dbapi 3.0, i think... :) > I think that this is too complex to be put into the standard, but how about > a generic cursor wrapper which shows how to write these kinds of filters? would be nice. at now i am just interested in wrapping up the standard to have better drivers, though. btw, how is the conversion to the new text format going? i am waiting for applying the first set of patches i sent to this list (no, i won't try to patch with types until we settle the argument, obviously.) ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Best friends are often failed lovers. -- Me From daniel.dittmar@sap.com Thu Mar 29 17:20:38 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Thu, 29 Mar 2001 19:20:38 +0200 Subject: [DB-SIG] RE: column type casting Message-ID: I'll try to summarize Frederico's proposal as I'm not sure I understood it correctly: Conversion python => db is done through the existing constructor (Date, DateFromTicks etc.) To convert db => python, the existing type objects (STRING, BINARY etc.) get an additional __call__ method. These are the default conversions. - they can be changed at the module level. In this case, the application has to implement the type comparison as well - to convert input at the connection or cursor level, only a callable object is required? My annotations: - if we don't allow changing module variables, do the type objects come into play at all? - I interpret Brian's ideas about 'consistent mechanism for converting' as following: db => python happens in 'driver space', so python => db should happen in driver space as well (using the constructors happens in 'user space', you call them explicit in the parameter list to .execute ()). > > How should a cursor behave when there is a new execute? > > - forget conversion information (fall back to connection > default, fall back > > to default at cursor creation time) > > - keep conversion by type > > conversion by type should be keeped, maybe even conversion by > position, > because you want to set the converion stuff once and then to > many queries > inside a loop, right? When you execute the same command again, then you'll want to keep the positional bindings. When you execute a different command (not that I would), positional bindings are bound to be wrong. Daniel P.S. Would anyone think it useful to have a Wiki added to this discussion? Not for the discussion itself. But it would be a fixed place for everyone to add proposals, example code and everything we agreed upon. This could then be more easily referenced than some snippets in a mailing list archive. -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From dario@ita.chalmers.se Fri Mar 30 11:26:42 2001 From: dario@ita.chalmers.se (Dario Lopez-Kästen) Date: Fri, 30 Mar 2001 13:26:42 +0200 Subject: [DB-SIG] Fw: [Zope] Who is willing to write a new database adapter? Message-ID: <007d01c0b90c$4bc8a280$33de1081@ita.chalmers.se> I am fowarding this to the Python-DB Sig list from the Zope list, since = it might get more attention here :-). Cheers! /dario ----- Original Message -----=20 From: "Ulrich Wisser" To: Sent: Friday, March 30, 2001 11:13 AM Subject: [Zope] Who is willing to write a new database adapter? > Hi, >=20 > we use the Adabas D database. I did not find any Python or > Zope database adapter for it. I tried to use the Perl-DBI > drivers but these have a lot of bugs. >=20 > Is there anybody willing to write a phyton driver and zope > adapter for Adabas D? >=20 > We would be willing to donate some money and of course all > software should be GPL. >=20 > If you are interessted, please contact me at u.wisser@publisher.de >=20 > Thanks >=20 > Ulrich > --=20 > Searchengine Know How - Webpromotion - Optimization - Internal Search > World Wide Web Publisher, Ulrich Wisser, Odensvag 13, S-14571 Norsborg > http://www.publisher.de Tel: +46-8-53460905 Fax: +46-8-534 609 06 >=20 >=20 > _______________________________________________ > Zope maillist - Zope@zope.org > http://lists.zope.org/mailman/listinfo/zope From mal@lemburg.com Fri Mar 30 12:36:17 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Mar 2001 14:36:17 +0200 Subject: [DB-SIG] Fw: [Zope] Who is willing to write a new database adapter? References: <007d01c0b90c$4bc8a280$33de1081@ita.chalmers.se> Message-ID: <3AC47DC1.7CDE84DF@lemburg.com> "Dario Lopez-Kästen" wrote: > > I am fowarding this to the Python-DB Sig list from the Zope list, since it might get more attention here :-). > > Cheers! > > /dario > > ----- Original Message ----- > From: "Ulrich Wisser" > To: > Sent: Friday, March 30, 2001 11:13 AM > Subject: [Zope] Who is willing to write a new database adapter? > > > Hi, > > > > we use the Adabas D database. I did not find any Python or > > Zope database adapter for it. I tried to use the Perl-DBI > > drivers but these have a lot of bugs. > > > > Is there anybody willing to write a phyton driver and zope > > adapter for Adabas D? You can use mxODBC to access Adabas from Python. There is also a Zope database adaptor for it.... http://www.lemburg.com/python/mxODBC.html The database interface for the Open Source SAP DB (www.sapdb.de) may also work with Adabas since they both have shared the same code base (at least at some point in the past)... http://www.sap.com/solutions/technology/sapdb/ > > We would be willing to donate some money and of course all > > software should be GPL. > > > > If you are interessted, please contact me at u.wisser@publisher.de > > > > Thanks > > > > Ulrich > > -- > > Searchengine Know How - Webpromotion - Optimization - Internal Search > > World Wide Web Publisher, Ulrich Wisser, Odensvag 13, S-14571 Norsborg > > http://www.publisher.de Tel: +46-8-53460905 Fax: +46-8-534 609 06 -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From daniel.dittmar@sap.com Fri Mar 30 12:16:08 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 30 Mar 2001 14:16:08 +0200 Subject: [DB-SIG] Fw: [Zope] Who is willing to write a new database ad apter? Message-ID: > we use the Adabas D database. I did not find any Python or > Zope database adapter for it. I tried to use the Perl-DBI > drivers but these have a lot of bugs. > > Is there anybody willing to write a phyton driver and zope > adapter for Adabas D? > > We would be willing to donate some money and of course all > software should be GPL. > > If you are interessted, please contact me at u.wisser@publisher.de For those interested: Adabas D uses ODBC as it's C API, even on Unix. So code for the ODBC Adapter should be reusable. It will be very problematic on Linux. The communication layer in the ODBC lib checks for changes in the process id. As Linux gives each thread a new process id, I'm not sure having a Zope adapter on linux for multiple threads is possible at all. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From Nides" This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C0B8E3.36398480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello- I have tried connecting to a Popy database via python and send query's = to the db, but i can not get it to work. I am not quite sure how to use = the fetchxxx() as well. Could someone please compose some sample could for me that would contain = how to connect and send a query to a PoPy database using theses specs: database name: Sampledb host:thales port:5432 user: dbuser password: xyz This is what the database looks like... Has a column named friends and = it contains there first and last name and there phone number.=20 --------------- Friends =20 --------------- last_name=20 ---------------- first_name=20 ---------------- phone =20 ---------------- Thank You Very Much! -Daivd ------=_NextPart_000_001B_01C0B8E3.36398480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello-
 
I have tried connecting to a Popy = database via=20 python and send query's to the db, but i can not get it to work. I am = not quite=20 sure how to use the fetchxxx() as well.
 
Could someone please compose some = sample could for=20 me that would contain how to connect and send a query to a PoPy database = using=20 theses specs:
 
database name: Sampledb
host:thales
port:5432
user: dbuser
password: xyz
 
This is what the database looks like... = Has a=20 column named friends and it contains there first and last name and there = phone=20 number.
---------------
Friends     =
---------------
last_name
----------------
first_name
----------------
phone       
----------------
 
Thank You Very Much!
 
-Daivd
------=_NextPart_000_001B_01C0B8E3.36398480-- From hme@informatik.uni-rostock.de Fri Mar 30 15:32:56 2001 From: hme@informatik.uni-rostock.de (hme@informatik.uni-rostock.de) Date: Fri, 30 Mar 2001 17:32:56 +0200 Subject: [DB-SIG] [ANNOUNCE] OpenIngres Module (DB API 2.0) In-Reply-To: <20010310202427.A19845@informatik.uni-rostock.de>; from hme@informatik.uni-rostock.de on Sat, Mar 10, 2001 at 08:24:27PM +0100 References: <20010310202427.A19845@informatik.uni-rostock.de> Message-ID: <20010330173256.C811@informatik.uni-rostock.de> You (hme@informatik.uni-rostock.de) wrote: > You will find a DB API 2.0 conforming module, that works with Ingres 6.4 > and OpenIngres at > > http://www.informatik.uni-rostock.de/~hme/software/ There was a string termination problem with CHAR (not VARCHAR). Thanks to Hamish Lawson! You will find a fixed version at: http://www.informatik.uni-rostock.de/~hme/software/ Peace Holger -- Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group hm at GUUG.de, http://www.informatik.uni-rostock.de/~hme/ From mal@lemburg.com Fri Mar 30 17:09:54 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 30 Mar 2001 19:09:54 +0200 Subject: [DB-SIG] ANN: Python DB API Specs in PEP-format Message-ID: <3AC4BDE2.7B0EB373@lemburg.com> Thanks to Andrew Kuchling, the Python Database API Specififcations 1.0 and 2.0 are now available as official PEPs: Version 1.0: http://python.sourceforge.net/peps/pep-0248.html Version 2.0: http://python.sourceforge.net/peps/pep-0249.html The main benefit from having these documents in PEP format is that we can now use the standard SourceForge tools to maintain them. Patches should be created against the CVS tree versions of the PEPs (which are ASCII documented formatted according to the PEP Guidelines in http://python.sourceforge.net/peps/pep-0001.html). You will find them in the directory python/nondist/peps after having checked out the Python CVS tree. -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From akuchlin@mems-exchange.org Fri Mar 30 21:11:18 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Fri, 30 Mar 2001 16:11:18 -0500 Subject: [DB-SIG] Re: unittests for DB-2.0 compliance In-Reply-To: ; from jodom@digicool.com on Fri, Mar 30, 2001 at 03:52:50PM -0500 References: Message-ID: <20010330161118.I17831@ute.cnri.reston.va.us> On Fri, Mar 30, 2001 at 03:52:50PM -0500, John Odom wrote: >Has anyone written unittests to determine if a module is >DB-2.0 compliant? >If not, I am currently writing some. Weren't the authors of psycopg working on a test set? I think implementing a set of test cases would be a very good idea, and would serve both to test compliance and the software's correctness. I'll be interested in seeing what people come up with. --amk From fog@mixadlive.com Fri Mar 30 22:54:22 2001 From: fog@mixadlive.com (Federico Di Gregorio) Date: Sat, 31 Mar 2001 00:54:22 +0200 Subject: [DB-SIG] Re: unittests for DB-2.0 compliance In-Reply-To: <20010330161118.I17831@ute.cnri.reston.va.us>; from akuchlin@mems-exchange.org on Fri, Mar 30, 2001 at 04:11:18PM -0500 References: <20010330161118.I17831@ute.cnri.reston.va.us> Message-ID: <20010331005422.O908@mixadlive.com> Scavenging the mail folder uncovered Andrew Kuchling's letter: > On Fri, Mar 30, 2001 at 03:52:50PM -0500, John Odom wrote: > >Has anyone written unittests to determine if a module is > >DB-2.0 compliant? > >If not, I am currently writing some. > > Weren't the authors of psycopg working on a test set? yes, we are. it is included in psycopg latest release, but it is a little bit young and lots of tests are missing. we plan to add the remaining tests next week and release it separately from psycopg in about 15 days. i already use it to test psycopg, popy and pygresql. > I think implementing a set of test cases would be a very good idea, > and would serve both to test compliance and the software's > correctness. I'll be interested in seeing what people come up with. the current testsuite implements only testing the connection and the types (i used it to test psycopg and the results are the long thread on types on this list ;) feel free to download from http://initd.org/ ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra From mal@lemburg.com Fri Mar 30 23:27:25 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 31 Mar 2001 01:27:25 +0200 Subject: [DB-SIG] ANN: eGenix.com mxODBC Database Interface Version 2.0.1 References: <3AC5158B.D34E8F27@lemburg.com> Message-ID: <3AC5165D.B129822A@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mxODBC Database Package for Python Version 2.0.1 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ?: The eGenix.com mxODBC Database Package for Python is part of the eGenix.com mx Extension Series for Python, a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. ________________________________________________________________________ WHAT'S NEW ? This patch release fixes a few problems which were found by users on Windows platforms: * Execution of SQL commands lead to a hanging Python processes for some users. * Handling of date/time values resulted in exceptions on some Windows configurations. Due to popular demand, I am now also providing precompiled Windows binaries for the older Python 1.5.2 version. Binaries for Python 2.1 will be announced after its final release. ________________________________________________________________________ SPECIAL OFFER theKompany.com has licensed the eGenix.com mx Commercial Package (which includes mxODBC) for inclusion in their brand new Qt-based Python IDE BlackAdder. It allows developing portable GUI-based database applications which run on Windows and Linux platforms without any change to the source code. BlackAdder includes a 1 CPU license for this package at no extra cost, so you may want to check out their great new product. See http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#BlackAdder for details. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0-3.5 interface for Python mxODBC is an extension package that provides a Python Database API compliant interface to ODBC capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). mxODBC allows you to interface to more than one database from one process, making inter-database interfacing very flexible and reliable. The source version includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The precompiled versions for Windows and Linux include the interfaces to the standard ODBC manager on these platforms to allow for a more easily configurable setup. More details are available at: http://www.lemburg.com/files/python/mxODBC.html ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.lemburg.com/files/python/ Note that in order to use mxODBC you will also need to install the eGenix.com mx BASE package which can be downloaded from the same location. ________________________________________________________________________ WHAT DOES IT COST ? mxODBC comes with a licenses which allows non-commercial use at no charge, but costs a moderate fee for commercial use. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#mxCOMMERCIAL for details. The package comes with full source code. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ REFERENCE:

eGenix.com mxODBC Package - eGenix.com mxODBC Database Interface 2.0.1 with distutils support and precompiled binaries for Windows and Linux. (31-Mar-2001) ________________________________________________________________________ Enjoy, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From h.e.w.frater@cs.cf.ac.uk Sat Mar 17 21:43:28 2001 From: h.e.w.frater@cs.cf.ac.uk (Hugh) Date: Sat, 17 Mar 2001 21:43:28 +0000 Subject: [DB-SIG] Including variables in SQL queries Message-ID: <01031721493400.00857@lap025.cs.cf.ac.uk> Hi All, I got DCOracle2 installed and working a while back and am progressing with the project OK. What I want to know, is how to include variables in an SQL query. This is so I can select an encryted password from a table given the userID which is parsed using the cgi.py module into a variable in my python script. The code I've got is as follows: Note I have yet to try this because the tables are not yet finalised. formid = form.getvalue('id') ....... c.execute("select password from tblborrower where userid = formid") I have a suspision that this won't work because it will try and use "formid" as the value for userid instead of the value of the string formid. I know there are probably better ways to make a secure login, but it's only a first year project, and it doesn't matter that much. Thanks in advance for any help. Hugh Frater