From clement@ans.com.au Mon Jun 3 02:03:57 2002 From: clement@ans.com.au (Clement) Date: Mon, 3 Jun 2002 11:03:57 +1000 Subject: [DB-SIG] Installing MySQL-python on python 2.2 In-Reply-To: <20020506112237.0c084ff0.wilk@flibuste.net> Message-ID: Do you know where can I download a copy of MySQL-python module that works with Python 2.2.1? The copy that is available at Sourceforge will install in /usr/lib/python2.1 only. Thank you very much for your help. Regards, Clement From andy47@halfcooked.com Mon Jun 3 02:18:59 2002 From: andy47@halfcooked.com (Andy Todd) Date: Mon, 03 Jun 2002 11:18:59 +1000 Subject: [DB-SIG] Installing MySQL-python on python 2.2 References: Message-ID: <3CFAC403.8040901@halfcooked.com> Clement wrote: > Do you know where can I download a copy of MySQL-python module that works > with Python 2.2.1? The copy that is available at Sourceforge will install > in /usr/lib/python2.1 only. > > Thank you very much for your help. > > Regards, > > Clement > > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > http://sourceforge.net/project/showfiles.php?group_id=22307&release_id=51760 Scroll down to the highlighted section (should be 0.91). If you are on Windows select the file with the name MySQL-python-0.9.1.win32-py2.2.exe. I can confirm that this works with Python 2.2.1. If you are not running Windows then get the source distribution and compile it yourself. If you get compilation errors when you have expanded the archive and then done 'python setup.py install' then post them here and we will try and help you out. If you are running Red Hat and have donwloaded the rpms then someone else will have to help you out. Regardless, its generally a good idea to let us know which operating system, distribution (and version) of Python, and which version of MySQL you are running. Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From clement@ans.com.au Mon Jun 3 02:34:24 2002 From: clement@ans.com.au (Clement) Date: Mon, 3 Jun 2002 11:34:24 +1000 Subject: [DB-SIG] Installing MySQL-python on python 2.2 In-Reply-To: <3CFAC403.8040901@halfcooked.com> Message-ID: Hi Andy, Thank you very much for your quick response. I am sorry that I did not supply the full details. I am running RH7.2 (will upgrade to 7.3 soon) on P-III CPU. I got the binary RPM from Sourceforge web site exactly as you have suggested. However, that binary rpm, MySQL-python-0.9.1.tar.gz, installs in /usr/lib/python2.1 instead of /usr/lib/python2.2. I cannot use it from Python 2.2.1. What would you suggest? Regards, Clement ANS Communications P/L =============================================== Post Addr: P O Box 6626 Blacktown BC, NSW 2148 Tel: 1300 300 266 Fax: 1300 300 331 > -----Original Message----- > From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf > Of Andy Todd > Sent: Monday, June 03, 2002 11:19 AM > To: Clement > Cc: db-sig@python.org > Subject: Re: [DB-SIG] Installing MySQL-python on python 2.2 > > > Clement wrote: > > Do you know where can I download a copy of MySQL-python module > that works > > with Python 2.2.1? The copy that is available at Sourceforge > will install > > in /usr/lib/python2.1 only. > > > > Thank you very much for your help. > > > > Regards, > > > > Clement > > > > > > > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > > > http://sourceforge.net/project/showfiles.php?group_id=22307&releas > e_id=51760 > > Scroll down to the highlighted section (should be 0.91). If you are on > Windows select the file with the name > MySQL-python-0.9.1.win32-py2.2.exe. I can confirm that this works with > Python 2.2.1. > > If you are not running Windows then get the source distribution and > compile it yourself. If you get compilation errors when you have > expanded the archive and then done 'python setup.py install' then post > them here and we will try and help you out. > > If you are running Red Hat and have donwloaded the rpms then someone > else will have to help you out. > > Regardless, its generally a good idea to let us know which operating > system, distribution (and version) of Python, and which version of MySQL > you are running. > > Regards, > Andy > -- > ---------------------------------------------------------------------- > From the desk of Andrew J Todd esq - http://www.halfcooked.com > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From andy47@halfcooked.com Mon Jun 3 02:56:08 2002 From: andy47@halfcooked.com (Andy Todd) Date: Mon, 03 Jun 2002 11:56:08 +1000 Subject: [DB-SIG] Installing MySQL-python on python 2.2 References: Message-ID: <3CFACCB8.1040505@halfcooked.com> Clement wrote: > Hi Andy, > > Thank you very much for your quick response. I am sorry that I did not > supply the full details. > > I am running RH7.2 (will upgrade to 7.3 soon) on P-III CPU. I got the > binary RPM from Sourceforge web site exactly as you have suggested. > However, that binary rpm, MySQL-python-0.9.1.tar.gz, installs in > /usr/lib/python2.1 instead of /usr/lib/python2.2. I cannot use it from > Python 2.2.1. > > What would you suggest? > > Regards, > > Clement > ANS Communications P/L > =============================================== > Post Addr: P O Box 6626 Blacktown BC, NSW 2148 > Tel: 1300 300 266 Fax: 1300 300 331 > > >>-----Original Message----- >>From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf >>Of Andy Todd >>Sent: Monday, June 03, 2002 11:19 AM >>To: Clement >>Cc: db-sig@python.org >>Subject: Re: [DB-SIG] Installing MySQL-python on python 2.2 >> >> >>Clement wrote: >> >>>Do you know where can I download a copy of MySQL-python module >> >>that works >> >>>with Python 2.2.1? The copy that is available at Sourceforge >> >>will install >> >>>in /usr/lib/python2.1 only. >>> >>>Thank you very much for your help. >>> >>>Regards, >>> >>>Clement >>> >>> >>> >>> >>>_______________________________________________ >>>DB-SIG maillist - DB-SIG@python.org >>>http://mail.python.org/mailman/listinfo/db-sig >>> >> >>http://sourceforge.net/project/showfiles.php?group_id=22307&releas >>e_id=51760 >> >>Scroll down to the highlighted section (should be 0.91). If you are on >>Windows select the file with the name >>MySQL-python-0.9.1.win32-py2.2.exe. I can confirm that this works with >>Python 2.2.1. >> >>If you are not running Windows then get the source distribution and >>compile it yourself. If you get compilation errors when you have >>expanded the archive and then done 'python setup.py install' then post >>them here and we will try and help you out. >> >>If you are running Red Hat and have donwloaded the rpms then someone >>else will have to help you out. >> >>Regardless, its generally a good idea to let us know which operating >>system, distribution (and version) of Python, and which version of MySQL >>you are running. >> >>Regards, >>Andy >>-- >>---------------------------------------------------------------------- >> From the desk of Andrew J Todd esq - http://www.halfcooked.com >> >> >> OK. The problem is probably with your installation rather than MySQL-python. Bearing in mind that I'm not a Red Hat user and I've never installed an RPM module. That aside, I'm not going to stop my crashing ignorance stop me from telling you what to do. I would suspect that python 2.1 is in your path ahead of python 2.2. Which version starts when you type 'python' at the command line? What do you see when you type 'which python'. If you have both versions installed and available to run in your environment, primarily by having the different executables in directories on your PATH, then you can get version conflicts. In the past I've seen similar problems when I'm running more than one version of Python and the order of the PATH entries is usually the key. If the installer finds the 2.1 lib directory first then that may be the reason it is used as the installation target. However, if you are running 2.2 by default the package *should* install into the 2.2 site-packages - I think. If for some reason you can't get that to work with the RPM then I would suggest you switch to the source distribution as that will play ball (I've installed it on Debian so I'm not completely ignorant on that point ;-) Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From kjcole@gri.gallaudet.edu Mon Jun 3 02:46:30 2002 From: kjcole@gri.gallaudet.edu (Kevin Cole) Date: Sun, 2 Jun 2002 21:46:30 -0400 (EDT) Subject: [DB-SIG] Installing MySQL-python on python 2.2 In-Reply-To: <3CFACCB8.1040505@halfcooked.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I am running RH7.2 (will upgrade to 7.3 soon) on P-III CPU. I got the > binary RPM from Sourceforge web site exactly as you have suggested. > However, that binary rpm, MySQL-python-0.9.1.tar.gz, installs in > /usr/lib/python2.1 instead of /usr/lib/python2.2. I cannot use it from > Python 2.2.1. One other potential source of trouble: Red Hat boxed themselves into a corner by making their installation program (and other stuff?) REQUIRE 1.5.2. So, when you install Python 2.x (if you installed Red Hat's RPM) it goes through some hoops to make sure that it has both the old and the new Python on there. Among other things, you end up with two execut- ables: "python" and "python2", as well as two sets of paths, etc. I'm not sure if this is impacting on you or if you've already taken care of such troubles. - -- Kevin Cole, RHCE, Linux Admin | E-mail: kjcole@gri.gallaudet.edu Gallaudet Research Institute | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | Voice: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8+sqBh8702ObzMscRAmd3AJ0dpYWXktXMHhcFngHESE7NTmraAACfXWiC P4NZIuRrBP/uQFZSFm0w680= =q8Rq -----END PGP SIGNATURE----- From clement@ans.com.au Mon Jun 3 03:29:06 2002 From: clement@ans.com.au (Clement) Date: Mon, 3 Jun 2002 12:29:06 +1000 Subject: [DB-SIG] Installing MySQL-python on python 2.2 In-Reply-To: Message-ID: Hi Andy and Kevin, Yes, Python 1.5.2 are Python 2.2.1 are both installed. Python 2.1, however, is not. I have checked all the environment variables and there is no reference at all to python 2.1. I have also removed the /usr/lib/python2.1 directory tree. I have tried the tar ball and get the following error message: # python2 setup.py build running build running build_py not copying CompatMysqldb.py (output up-to-date) not copying _mysql_exceptions.py (output up-to-date) not copying MySQLdb/__init__.py (output up-to-date) not copying MySQLdb/converters.py (output up-to-date) not copying MySQLdb/connections.py (output up-to-date) not copying MySQLdb/cursors.py (output up-to-date) not copying MySQLdb/sets.py (output up-to-date) not copying MySQLdb/times.py (output up-to-date) not copying MySQLdb/constants/__init__.py (output up-to-date) not copying MySQLdb/constants/CR.py (output up-to-date) not copying MySQLdb/constants/FIELD_TYPE.py (output up-to-date) not copying MySQLdb/constants/ER.py (output up-to-date) not copying MySQLdb/constants/FLAG.py (output up-to-date) not copying MySQLdb/constants/REFRESH.py (output up-to-date) not copying MySQLdb/constants/CLIENT.py (output up-to-date) running build_ext Traceback (most recent call last): File "setup.py", line 123, in ? extra_objects=extra_objects, File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/core.py", line 138, in setup dist.run_commands() File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/dist.py", line 913, in run_command cmd_obj.run() File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/dist.py", line 913, in run_command cmd_obj.run() File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/command/build_ext.p y", line 231, in run customize_compiler(self.compiler) File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/sysconfig.py", line 126, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/sysconfig.py", line 408, in get_config_vars func() File "/var/tmp/python2-2.2.1-root/usr/lib/python2.2/distutils/sysconfig.py", line 313, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/lib/python2.2/config/Makefile (No such file or directory) Regards, Clement > -----Original Message----- > From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf > Of Kevin Cole > Sent: Monday, June 03, 2002 11:47 AM > To: Andy Todd > Cc: Clement; db-sig@python.org > Subject: Re: [DB-SIG] Installing MySQL-python on python 2.2 > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > I am running RH7.2 (will upgrade to 7.3 soon) on P-III CPU. I got the > > binary RPM from Sourceforge web site exactly as you have suggested. > > However, that binary rpm, MySQL-python-0.9.1.tar.gz, installs in > > /usr/lib/python2.1 instead of /usr/lib/python2.2. I cannot use it from > > Python 2.2.1. > > One other potential source of trouble: Red Hat boxed themselves into a > corner by making their installation program (and other stuff?) REQUIRE > 1.5.2. So, when you install Python 2.x (if you installed Red Hat's RPM) > it goes through some hoops to make sure that it has both the old and the > new Python on there. Among other things, you end up with two execut- > ables: "python" and "python2", as well as two sets of paths, etc. I'm > not sure if this is impacting on you or if you've already taken care of > such troubles. > > - -- > Kevin Cole, RHCE, Linux Admin | E-mail: kjcole@gri.gallaudet.edu > Gallaudet Research Institute | WWW: > http://gri.gallaudet.edu/~kjcole/ > Hall Memorial Bldg S-419 | Voice: (202) 651-5135 > Washington, D.C. 20002-3695 | FAX: (202) 651-5746 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8+sqBh8702ObzMscRAmd3AJ0dpYWXktXMHhcFngHESE7NTmraAACfXWiC > P4NZIuRrBP/uQFZSFm0w680= > =q8Rq > -----END PGP SIGNATURE----- > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From phoengeist38259@arcor.de" Entschuldigen Sie bitte die Störung! Mir ist etwas zu Ohren gekommen. Eine relativ aussergewöhnliche Gerüchteküche, aus der man mir ein schwerverdauliches Süppchen vorgesetzt hat, ist der Grund meiner Mail. Unappetitlich ist gar kein Ausdruck! Ist es möglich auf funktechnischem Wege(in welchen Frequenzbereichen?) jemanden zu beeinflussen oder zu manipulieren? Oder sogar zu schikanieren und terrorisieren? Unter dem Motto:"Einen am Sender?Nich ganz alleine? Kleine Mannim Ohr?Falsche Wellenlänge?Bohnen in den Ohren? Auf den Zahn gefühlt(Amalgam)?Mal unverbindlich reinhören? Der Pullacher Wanzentanz? Ist das Spinnerei?Das geht doch gar nicht,oder? Und wenn wie sieht das ethisch moralisch aus? Zur technischen Seite der Sache gibt es zwar Berichte und Webseiten: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. ,aber,das kann doch nicht sein,das soetwas gemacht wird,oder? Eine Menschenrechtsverletzung sonder gleichen!?! Ist es möglich,durch Präparation,der Ohren und im Zusammenspiel mit eventuell vorhandenem Zahnersatz? Mit relativ einfacher Funktechnik?? In diesem Land?Hier und heute??? Unter welchen Motiven? Wo ist eigentlich die Abteilung 5 des BND und des Verfassungsschutzes? Kann es sein,daß es Leute gibt,die dem BND/Verfassungsschutz,auf funktechnischem Wege permanent einen Situationsbericht abliefern,ohne es selbst zu merken,im Kindesalter machbar gemacht?? Werden durch solche inoffiziellen Mitarbeiter,beim BND und Verfassungsschutz,nach Stasimanier, Informationen von und über,rein theoretisch, jeden Bundesbürger,gesammelt? Gibt es dann noch ein Recht auf Privatsphere? Wer kontrolliert eigentlich den BND,MAD und Verfassungsschutz auf Unterwanderung??? In der Mail geht es mir eigentlich um die Frage,ob es kriminellen Elementen, aus dem Motiv der Bereicherung,oder Gruppierungen aus ideologischen Motiven, möglich ist ,sich Wissen und Technik anzueignen,die zu anderen Zeiten, aus anderen Motiven(Westfernsehen?),entwickelt wurde. Und stellt der technische Wissensstand, der der Allgemeinheit bekannt ist wirklich das Ende der Fahnenstange dar? Ist es denn nicht kriminellen Elementen genauso möglich, ich sage das jetzt mal verharmlost und verniedlichend, einzelne Personen oder Gruppen mit relativ einfachen Mitteln, aus welchen Motiven auch immer, auszuspionieren? Und stellt diese "Ausspioniererei" nicht einen erheblichen Eingriff in die Privatsphäre dar? Ist es möglich einzelne Personen oder Gruppen, eine Akzeptans einer gewissen Öffentlichkeit(suggeriert?), die z.B. mit Hilfe von Internetseiten,wie zum Beispiel dem "Pranger"geschaffen werden könnte, mal vorausgestzt,zu terroriesieren und oder zu schikanieren, und das in aller (suggerierten)Öffentlichkeit?Haben die Leute die da am Pranger, oder auf irgendeiner anderen Seite verunglimpft,oder gar Verleumdet werden, eigentlich eine Chance zur Gegenöffentlichkeit?Ist das nicht Rufmord? Vor einigen Jahren bin ich per Zufall auf die Seite "Der Pranger" gestoßen, damals lief das noch nicht unter dem Deckmantel der Partnervermittlung. Können sich einzelne Personen,oder Interessengemeinschaften, aus reinem Selbstzweck,solcher Seiten bedienen, um unter dem Deckmantel einer fragwürdigen Zivilkourage, durch anzetteln irgendwelcher Hetzkampagnen,eigene, ganz persöhnliche Interessen durchsetzen? Können solche Seiten zur Koordination von kriminellen machenschaften dienen? Die Frage,ist es Möglichkeit oder Unmöglichkeit,technisch und gesellschaftlich, einzelne Personen,oder auch Gruppierungen,aus einer kriminellen/ideologischen Energei heraus,zu manipulieren oder zu beeinflussen,terrorisieren oder zu schickanieren,und zwar gezielt. Zielgruppenmanipulation durch Massenmedien sind alltägliche Manipulation, der mansich,mehr oder weniger,entziehen kann. Wird das Recht auf Privatsphäre,schleichend,tiefenpsychologisch, durch Sendungen,wie,zum Beispiel "Big brother",untergraben? Sollte bei einem der Angemailten ein gewisser Wissensstand zum Thema vorhanden sein, wäre ich über Hinweise zum Thema froh. Auf der Suche nach Antworten auf meine Fragen maile ich verschiedene Adressen aus dem Internet an, und hoffe aufkonstruktive Antworten und Kritiken. Über einen Besuch auf der Seite würde ich mich freuen. Sollten Sie von mir mehrfach angeschrieben worden sein,so bitte ich Sie,mir dies zu entschuldigen, das war nicht beabsichtigt. Der Grund für meine Anonymität ist die Tatsache, daß bei derlei Fragenstellerei, verständlicherweise,schnell der Ruf nach der Psychatrie laut wird. Was auch Methode hat(ist). Sollten Sie die Mail als Belästigung empfinden, möchte ich mich hiermit dafür entschuldigen! Big brother is watching you? Excuse please the disturbance! Me something came to ears. A relatively unusual rumor kitchen, from which one put forward to me a heavydigestible soup, is the reason of my Mail. Unappetizing is no printout! Is it possible on radio Wege(in for which frequency ranges?) to influence or manipulate someone? Terrorize or to even chicane and? Under the Motto:"Einen at the Sender?Nich quite alone? Small Mannim Ohr?Fal Wellenlaenge?Bohnen in the ears? On the tooth clean-hear gefuehlt(Amalgam)?Mal witthout obligation? The Pullacher bug wanzentanz? Isn't the Spinnerei?Das goes nevertheless at all, or? And if as looks ethicalally morally? For the technical page of the thing there is to report and web page: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. but, that cannot be nevertheless, which is made soetwas, or? A violation of human rights resemble special!?! Is it possible, by preparation, the ears and in interaction with possibly available artificial dentures? With relatively simple radio engineering?? In this Land?Hier and today??? Under which motives? Where is the department actually 5 of the BND and the protection of the constitution? Can it be that there are people, which deliver the Federal Intelligence Service/protection of the constitution, on radio way permanently a situation report, without noticing it, in the infancy feasiblly made? By such unofficial coworkers, with the BND and protection of the constitution, after Stasimanier, is information collected of and over,purely theoretically, each Federal citizen? Is there then still another right to Privatsphere? Who actually checks the BND, WAD and protection of the constitution for infiltration??? Into the Mail actually concerns it to me the question whether it criminal items, from which motive of enriching, or groupings from ideological motives is possible, to acquire itself knowledge and technique which were developed at other times, from other Motiven(Westfernsehen?).And does the technical knowledge status place, to that the public admits is really the end of the flag bar? Is it not to criminal items just as possible, I legend that now times played down and does nice-end, individual persons or groups with relatively simple means, to spy from whatever motives always? And doesn't this " Ausspioniererei " represent a substantial intervention into the privatsphaere? It is possible individual persons or groups, one acceptance to of a certain Oeffentlichkeit(suggeriert?), e.g. by Internet pages, how for example the " Pranger"geschaffen could become, times vorausgestzt, to terroriesieren and or chicane, and in everything (the people suggerierten)Oeffentlichkeit?Haben there at the Pranger, or on any other page to be reviled, or slandered, actually a chance to the Gegenoeffentlichkeit?Ist that not character assassination? Some years ago I am by coincidence the page " the Pranger " encountered, at that time ran not yet under the cover of the partner switching.Itself can individual persons, or communities of interests, from pure self purpose, such pages to serve, over under the cover of a doubtful Zivilkourage, through plot any rushing campaigns, own, quite persoehnliche interests to intersperse? Can such pages serve for the co-ordination of criminal machinations? The question, is it possibility or impossibility, technically and socially, individual persons, or also groupings of manipulating or of influencing from an criminal/ideological Energei, terrorizes or to schickanieren, directed.Target group manipulation by mass media are everyday manipulation, from which, more or less, can extract itself. Does the right to privatsphaere, creeping, by transmissions become deep psychological, how, for example " Big undermine brother"? If the Angemailten should be available a certain knowledge status to the topic with one, I would be glad over notes to the topic On the search for responses to my questions maile I different addresses from the Internet on, and hope up-constructional responses and criticisms.Over an attendance on the page wuerde I are pleased.If you should have been written down by me several times, then please I you to excuse me this that was not intended. The reason for my anonymity is the fact that with such Fragenstellerei, understandably, fast after the call the Psychatrie loud becomes. Which also method hat(ist). If you should feel the Mail as annoyance, I would like to apologize hereby for it! Big is watching you? Veuillez excuser le dérangement! Moi quelque chose concernant des oreilles est venu. Une cuisine de bruit relativement inhabituelle, dont on m'a placé un Sueppchen schwerverdauliches devant, est la raison de mes Mail.Aucune expression n'est peu appétissante! Il est possible sur un Wege(in funktechnischem pour quelles réponses fréquentielles?) quelqu'un influencer ou manipuler? Ou même schikanieren et terroriser? Sous le Motto:"Einen au Sender?Nich tout à fait seulement? Petits Mannim Ohr?Falsche Wellenlaenge?Bohnen dans les oreilles? Sur la dent gefuehlt(Amalgam)?Mal non contraignant reinhoeren? Le Pullacher Wanzentanz? Le Spinnerei?Das n'est-il quand même pas du tout va, ou? Et si comme cela paraît éthiquement moralement? Au côté technique de la chose, il y a certes des rapports et des Webseiten: Totalitaer,de - Die Waffe gegen die Kritik http://www.raum-und-zeit.com/Aktuell/Brummton.htm http://www.fosar-bludorf.com/Tempelhof/ http://jya.com/haarp.htm http://www.zeitenschrift.at/magazin/zs_24_15/1_mikrowaffen.htm http://www.bse-plus.de/d/doc/lbrief/lbmincontr.htm http://home.nexgo.de/kraven/bigb/big3.html http://w3.nrl.navy.mil/projects/haarp/index.html http://cryptome.org/ http://www.raven1.net/ravindex.htm http://www.calweb.com/~welsh/ http://www.cahe.org/ http://www.parascope.com/ds/mkultra0.htm http://www.trufax.org/menu/mind.html http://www.trufax.org/menu/elect.html http://mindcontrolforum.com/ http://www.trufax.org/menu/elect.html usw. usw. usw. toutefois qui ne peut quand même pas être qui on fait soetwas, ou? Une violation des droits de l'homme séparer ressembler!?! Il est possible, par la préparation, des oreilles et dans l'effet avec la prothèse dentaire éventuellement existante? Avec la technique de radio relativement simple?? Dans ce Land?Hier et aujourd'hui Sous quels motifs? Où le département est-il en réalité 5 du BND et de la protection d'constitution? peut il être qu'il y a les personnes qui livrent en permanence le BND/Verfassungsschutz, de manière funktechnischem un rapport de situation, sans le remarquer le -même , dans l'enfance rendu possible?? Par de tels collaborateurs officieux, avec le BND et la protection d'constitution, après manière, des informations sont-elles rassemblées et plus de, purement théoriquement, chaque citoyen allemand? Il y a alors encore un droit à des Privatsphere? Qui contrôle en réalité le BND, mad et protection d'constitution sur une infiltration??? Il s'agit en réalité dans le Mail me la question de savoir si lui éléments criminels, dont le motif de l'enrichissement, ou de groupements des motifs idéologiques, possible de s'acquérir le savoir et la technique qui à d'autres temps, est autre MotivenEt place-t-il le savoir technique dont le public vraiment la fin la barre de drapeau a connaissance ? Il n'est pas donc exactement la même chose possible pour des éléments criminels, moi cela maintenant fois verharmlost et minimisant une légende, personnes ou groupes particuliers avec des moyens relativement simples, de quels motifs aussi toujours, auszuspionieren?(Westfernsehen?), a été développé. Et ce "Ausspioniererei" ne représente-t-il pas une intervention considérable dans la vie privée? Il est possible personnes ou groupes particuliers, pour certain Oeffentlichkeit(suggeriert?), celui p. ex. à l'aide des côtés Internet, comme par exemple "le Pranger"geschaffen pourrait, fois vorausgestzt schikanieren terroriesieren et ou , et qui toute (suggerierten)Oeffentlichkeit?Haben les personnes ceux là, ou d'un autre côté verunglimpft, ou on ne pas calomnie, en réalité une chance au Gegenoeffentlichkeit?Ist qui meurtre d'appel? Il y a quelques années, je ne suis pas encore par hasard sur le côté "celui" poussé, fonctionnais alors cela sous la couche de pont de l'entremise partenaire. Des personnes particulières, ou des communautés d'intérêts le peuventelles, d'un autobut pur, de tels côtés servent, sous la couche de pont d'un Zivilkourage douteux, tracent plus de des campagnes de précipitation, propres intérêts tout à fait persoehnliche entremêlent? De tels côtés peuvent-ils servir à la coordination des manoeuvres criminelles? Question, est lui possibilité ou impossibilité de manipuler ou d'influencer techniquement et socialement, particulière personnes, ou aussi groupements, criminelle/ponctuel idéologique Energei dehors, , terroriser ou schickanieren, et ce.Une manipulation de groupe cible par des masse-médias être la manipulation quotidienne qui peut extraire mansich, plus ou moins. Le droit à la vie privée est-il miné, ramment, tiefenpsychologisch, par des envois, comme, par exemple "des Big brother"? Avec un les Angemailten si un certain savoir devait exister sur le thème, je serais heureux sur des indications sur le thème.Sur la recherche des réponses à mes questions je différentes adresses maile d'Internet dessus, et espère réponses et critiques aufkonstruktive. Sur une visite du côté http://hometown.aol.de/reinerhohn38259/homepage/index.html> je me réjouirais. Si vous deviez avoir été écrit à différentes reprises par moi, je vous demande de m'excuser cela qui n'était pas envisagé. La raison de mon anonymat est le fait qu'avec telle des Fragenstellerei, l'appel devient ce qui est bien compréhensible, rapidement bruyant après le Psychatrie. Ce que la méthode a également (ist). Si vous deviez ressentir les Mail comme un ennui, je voudrais m'excuser par ceci pour cela! Big brother is watching you? From clement@ans.com.au Mon Jun 3 14:33:57 2002 From: clement@ans.com.au (Clement) Date: Mon, 3 Jun 2002 23:33:57 +1000 Subject: [DB-SIG] Installing MySQL-python on python 2.2 In-Reply-To: <3CFACCB8.1040505@halfcooked.com> Message-ID: Hi Andy, I get it work from the source code finally. Having been using the binary rpm's for sometime, I forgot that to install from the source, I need the MySQL-devel rpm. The problem solved after that is installed. And so I hope that this can help someone with similar problem. And thank you very much of your assistance. Regards, Clement > -----Original Message----- > From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf > Of Andy Todd > Sent: Monday, June 03, 2002 11:56 AM > To: Clement > Cc: db-sig@python.org > Subject: Re: [DB-SIG] Installing MySQL-python on python 2.2 > > > Clement wrote: > > Hi Andy, > > > > Thank you very much for your quick response. I am sorry that I did not > > supply the full details. > > > > I am running RH7.2 (will upgrade to 7.3 soon) on P-III CPU. I got the > > binary RPM from Sourceforge web site exactly as you have suggested. > > However, that binary rpm, MySQL-python-0.9.1.tar.gz, installs in > > /usr/lib/python2.1 instead of /usr/lib/python2.2. I cannot use it from > > Python 2.2.1. > > > > What would you suggest? > > > > Regards, > > > > Clement > > ANS Communications P/L > > =============================================== > > Post Addr: P O Box 6626 Blacktown BC, NSW 2148 > > Tel: 1300 300 266 Fax: 1300 300 331 > > > > > >>-----Original Message----- > >>From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf > >>Of Andy Todd > >>Sent: Monday, June 03, 2002 11:19 AM > >>To: Clement > >>Cc: db-sig@python.org > >>Subject: Re: [DB-SIG] Installing MySQL-python on python 2.2 > >> > >> > >>Clement wrote: > >> > >>>Do you know where can I download a copy of MySQL-python module > >> > >>that works > >> > >>>with Python 2.2.1? The copy that is available at Sourceforge > >> > >>will install > >> > >>>in /usr/lib/python2.1 only. > >>> > >>>Thank you very much for your help. > >>> > >>>Regards, > >>> > >>>Clement > >>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>DB-SIG maillist - DB-SIG@python.org > >>>http://mail.python.org/mailman/listinfo/db-sig > >>> > >> > >>http://sourceforge.net/project/showfiles.php?group_id=22307&releas > >>e_id=51760 > >> > >>Scroll down to the highlighted section (should be 0.91). If you are on > >>Windows select the file with the name > >>MySQL-python-0.9.1.win32-py2.2.exe. I can confirm that this works with > >>Python 2.2.1. > >> > >>If you are not running Windows then get the source distribution and > >>compile it yourself. If you get compilation errors when you have > >>expanded the archive and then done 'python setup.py install' then post > >>them here and we will try and help you out. > >> > >>If you are running Red Hat and have donwloaded the rpms then someone > >>else will have to help you out. > >> > >>Regardless, its generally a good idea to let us know which operating > >>system, distribution (and version) of Python, and which version of MySQL > >>you are running. > >> > >>Regards, > >>Andy > >>-- > >>---------------------------------------------------------------------- > >> From the desk of Andrew J Todd esq - http://www.halfcooked.com > >> > >> > >> > > OK. The problem is probably with your installation rather than > MySQL-python. > > Bearing in mind that I'm not a Red Hat user and I've never installed an > RPM module. That aside, I'm not going to stop my crashing ignorance stop > me from telling you what to do. > > I would suspect that python 2.1 is in your path ahead of python 2.2. > Which version starts when you type 'python' at the command line? What do > you see when you type 'which python'. If you have both versions > installed and available to run in your environment, primarily by having > the different executables in directories on your PATH, then you can get > version conflicts. > > In the past I've seen similar problems when I'm running more than one > version of Python and the order of the PATH entries is usually the key. > If the installer finds the 2.1 lib directory first then that may be the > reason it is used as the installation target. However, if you are > running 2.2 by default the package *should* install into the 2.2 > site-packages - I think. > > If for some reason you can't get that to work with the RPM then I would > suggest you switch to the source distribution as that will play ball > (I've installed it on Debian so I'm not completely ignorant on that > point ;-) > > Regards, > Andy > -- > ---------------------------------------------------------------------- > From the desk of Andrew J Todd esq - http://www.halfcooked.com > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From bfergo@ihug.com.au Tue Jun 4 07:31:12 2002 From: bfergo@ihug.com.au (Ben) Date: Tue, 4 Jun 2002 16:31:12 +1000 Subject: [DB-SIG] SQL insert with integer variable Message-ID: <007601c20b91$83963d20$5484adcb@pc> This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C20BE5.3D9F1F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm having trouble using one of my instance integer variable in a sql = insert statement.=20 Does Anyone have any ideas how to fix this? Cheers Ben ------=_NextPart_000_0073_01C20BE5.3D9F1F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm having trouble using one of my = instance integer=20 variable in a sql insert statement.
 
Does Anyone have any ideas how to fix=20 this?
 
Cheers
 
Ben
------=_NextPart_000_0073_01C20BE5.3D9F1F90-- From dyoo@hkn.eecs.berkeley.edu Tue Jun 4 07:54:42 2002 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Mon, 3 Jun 2002 23:54:42 -0700 (PDT) Subject: [DB-SIG] SQL insert with integer variable In-Reply-To: <007601c20b91$83963d20$5484adcb@pc> Message-ID: On Tue, 4 Jun 2002, Ben wrote: > I'm having trouble using one of my instance integer variable in a sql > insert statement. > > Does Anyone have any ideas how to fix this? Hi Ben, Can you show us some of the code that you're using, as well as an error message? Without this information, we're bound to misguess what's going on. Talk to you later! From bfergo@ihug.com.au Tue Jun 4 08:12:40 2002 From: bfergo@ihug.com.au (Ben) Date: Tue, 4 Jun 2002 17:12:40 +1000 Subject: [DB-SIG] RE: SQL insert with integer variable Message-ID: <00ad01c20b97$3975e4b0$5484adcb@pc> This is a multi-part message in MIME format. ------=_NextPart_000_00AA_01C20BEB.08A02BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm using the htmlxmlsql2000db module. If i just switch it toa 0 or a 5 all my code works perfect. I'm having trouble with this code: current_scene_int =3D 0 os.environ['http_proxy']=3D'' db=3Dhtmlxmlsql2000db.Connect(host=3D'isys3113.it.usyd.edu.au', = db=3D'usyddb',user=3D'grouplogin',passwd=3D'group') c=3Ddb.cursor() query=3D"insert into playscene (scene_id,title,scene) Values = (current_scene_int, '"+current_play+"','"+current_scene+"')" c.execute(query) it gives me this error: "The name 'current_scene_int' is not permitted in this context. Only = constants, expressions, or variables allowed here. Column names are not = permitted.", 'HResult': '0x80040e14', 'Source': 'Microsoft OLE DB = Provider for SQL Server'} ----- Original Message -----=20 From: "Danny Yoo" To: "Ben" Cc: Sent: Tuesday, June 04, 2002 4:54 PM Subject: Re: [DB-SIG] SQL insert with integer variable >=20 >=20 > On Tue, 4 Jun 2002, Ben wrote: >=20 > > I'm having trouble using one of my instance integer variable in a = sql > > insert statement. > > > > Does Anyone have any ideas how to fix this? >=20 > Hi Ben, >=20 > Can you show us some of the code that you're using, as well as an = error > message? Without this information, we're bound to misguess what's = going > on. >=20 >=20 > Talk to you later! >=20 >=20 >=20 > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig >=20 ------=_NextPart_000_00AA_01C20BEB.08A02BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm using the htmlxmlsql2000db module.
 
If i just switch it toa 0 or a 5 all my code works perfect.
 
I'm having trouble with this code:
 
current_scene_int =3D 0
os.environ['http_proxy']=3D''
db=3Dhtmlxmlsql2000db.Connect(host=3D= 'isys3113.it.usyd.edu.au',=20 db=3D'usyddb',user=3D'grouplogin',passwd=3D'group')
c=3Ddb.cursor()
query=3D"insert into playscene (scene_id,title,scene) Values=20 (current_scene_int,=20 '"+current_play+"','"+current_scene+"')"
c.execute(query)
 
it gives me this error:
 
"The name 'current_scene_int' is not permitted in this context. = Only=20 constants, expressions, or variables allowed here. Column names are not=20 permitted.", 'HResult': '0x80040e14', 'Source': 'Microsoft OLE DB = Provider for=20 SQL Server'}
 
 
----- Original Message -----=20
From: "Danny Yoo" <dyoo@hkn.eecs.berkeley.edu= >
To: "Ben" <bfergo@ihug.com.au>
Sent: Tuesday, June 04, 2002 4:54 PM
Subject: Re: [DB-SIG] SQL insert with integer variable

>
>
> On Tue, 4 Jun 2002, Ben = wrote:
>=20
> > I'm having trouble using one of my instance integer = variable in a=20 sql
> > insert statement.
> >
> > Does Anyone = have=20 any ideas how to fix this?
>
> Hi Ben,
>
> Can = you=20 show us some of the code that you're using, as well as an error
>=20 message?  Without this information, we're bound to misguess what's=20 going
> on.
>
>
> Talk to you later!
> =
>=20
>
> = _______________________________________________
> DB-SIG=20 maillist  -  DB-SIG@python.org
> http://mail.pytho= n.org/mailman/listinfo/db-sig
>=20
------=_NextPart_000_00AA_01C20BEB.08A02BD0-- From dyoo@hkn.eecs.berkeley.edu Tue Jun 4 08:44:19 2002 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Tue, 4 Jun 2002 00:44:19 -0700 (PDT) Subject: [DB-SIG] RE: SQL insert with integer variable In-Reply-To: <00ad01c20b97$3975e4b0$5484adcb@pc> Message-ID: On Tue, 4 Jun 2002, Ben wrote: > I'm having trouble with this code: > > current_scene_int = 0 > os.environ['http_proxy']='' > db=htmlxmlsql2000db.Connect(host='isys3113.it.usyd.edu.au', db='usyddb',user='grouplogin',passwd='group') > c=db.cursor() > query="insert into playscene (scene_id,title,scene) Values > (current_scene_int, '"+current_play+"','"+current_scene+"')" > c.execute(query) > > it gives me this error: > > "The name 'current_scene_int' is not permitted in this context. Only > constants, expressions, or variables allowed here. Column names are not > permitted.", 'HResult': '0x80040e14', 'Source': 'Microsoft OLE DB > Provider for SQL Server'} Ah! There's a bug in the query: > query="insert into playscene (scene_id,title,scene) Values > (current_scene_int, '"+current_play+"','"+current_scene+"')" > c.execute(query) Try printing out the 'query' string right before you execute it. You'll see something suspicious about the first value. In particular, it won't be a number. By the way, you might be able to avoid the bug altogether by not doing string concatenation: either string formatting or using prepared-statement format is often safer and easier to write. An alternative to what you have, using string formatting, might look like this: ### query = """insert into playscene (scene_id,title,scene) Values (%s, '%s', '%s')""" % (current_scene_int, current_play, current_scene) ### Also, be aware that you may need to sql-quote certain characters like "'". For example, if someone feeds in the play "A Midsummer Night's Dream", Bad Things will happen unless you quote that quote. Using a prepared format is probably even better, because it handles quotation issues for you. See the documentation on cursor.execute() for more details on this: http://python.org/topics/database/DatabaseAPI-2.0.html Best of wishes! From gerhard@bigfoot.de Tue Jun 4 08:44:34 2002 From: gerhard@bigfoot.de (Gerhard =?unknown-8bit?Q?H=E4ring?=) Date: Tue, 4 Jun 2002 09:44:34 +0200 Subject: [DB-SIG] RE: SQL insert with integer variable In-Reply-To: <00ad01c20b97$3975e4b0$5484adcb@pc> References: <00ad01c20b97$3975e4b0$5484adcb@pc> Message-ID: <20020604074434.GB23780@gargamel.hqd-internal> * Ben [2002-06-04 17:12 +1000]: > I'm using the htmlxmlsql2000db module. Which is probably unknown outside a certain australian university. Google sez it's sort of a xmlrpc solution to access a M$ SQL server remotely. > query="insert into playscene (scene_id,title,scene) Values (current_scene_int, '"+current_play+"','"+current_scene+"')" > c.execute(query) Ugh. This is exactly what not to do with a DB-API module. Provide the parameters for your statements in the second parameter of the execute statement. I have no idea what paramstyle your db module uses, but if it is pyformat or format, this should work: query = "insert into playscene (scene_id, title, scene) values (%i, %s, %s)" my_id = 5 my_title = "foo" my_scene = "bar" c.execute(query, (my_id, my_title, my_scene)) I'd suggest you read the docs of your DB-API module. They should provide examples for proper usage of the execute statement. And also for what paramstyle it uses. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From andy@dustman.net Tue Jun 4 14:43:02 2002 From: andy@dustman.net (Andy Dustman) Date: 04 Jun 2002 09:43:02 -0400 Subject: [DB-SIG] Installing MySQL-python on python 2.2 In-Reply-To: References: Message-ID: <1023198182.1524.13.camel@4.0.0.10.in-addr.arpa> On Sun, 2002-06-02 at 21:34, Clement wrote: > I am running RH7.2 (will upgrade to 7.3 soon) on P-III CPU. I got the > binary RPM from Sourceforge web site exactly as you have suggested. > However, that binary rpm, MySQL-python-0.9.1.tar.gz, installs in > /usr/lib/python2.1 instead of /usr/lib/python2.2. I cannot use it from > Python 2.2.1. Ahem. MySQL-python-0.9.1.tar.gz is not a binary RPM... Also note that Red Hat 7.3 includes MySQL-python-0.9.1, although it is for Python-1.5.2. I'm going to try to put out a 0.9.2 release candidate today. One interesting addition is the RPM package naming follows the python.org RPM naming convention, and depends on what python you used to build: Python Python MySQL-python Version Package Name Package Name ------- ------------ ------------ 1.5.2 python MySQL-python 2.1.3 python2.1 MySQL-python2.1 2.2.1 python2 MySQL-python2 With this scheme, you can install all three versions at once without any conflicts, if you so desire. The module name (MySQLdb) will not vary, of course. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all that I yam." -- Popeye From kimtitu@yahoo.com Wed Jun 5 01:43:31 2002 From: kimtitu@yahoo.com (Titu Kim) Date: Tue, 4 Jun 2002 17:43:31 -0700 (PDT) Subject: [DB-SIG] Help on this query Message-ID: <20020605004331.43105.qmail@web14704.mail.yahoo.com> Hi there, I have two unrelated tables A and B which store different data. Let say the followings are the table schemas, Table A ID number, Date number, EarnA number Table B ID number, Date number, EarnB number ID in Table A and Table B is the same data. Assume Date in Table A and Table B is in number format. I can get EarnA from Table A with this query Select sum(EarnA) from TableA where ID=XX and Date between mmm and nnn; Similar for TableB i can get EarnB Select sum(EarnA) from TableB where ID=XX and Date between mmm and nnn; The number of rows in TableA and TableB are different and EarnA and EarnB are two different data. Now if i want to show EarnA and EarnB in one query for the same ID in both Tables, how can i do this? Table schemeas are simplified for discussion purposes. Thanks. __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From andy47@halfcooked.com Wed Jun 5 02:57:40 2002 From: andy47@halfcooked.com (Andy Todd) Date: Wed, 05 Jun 2002 11:57:40 +1000 Subject: [DB-SIG] Help on this query References: <20020605004331.43105.qmail@web14704.mail.yahoo.com> Message-ID: <3CFD7014.7090002@halfcooked.com> Titu Kim wrote: > Hi there, > I have two unrelated tables A and B which store > different data. Let say the followings are the table > schemas, > > Table A > ID number, > Date number, > EarnA number > > Table B > ID number, > Date number, > EarnB number > > ID in Table A and Table B is the same data. Assume > Date in Table A and Table B is in number format. I can > get EarnA from Table A with this query > > Select sum(EarnA) from TableA > where ID=XX and Date between mmm and nnn; > > Similar for TableB i can get EarnB > Select sum(EarnA) from TableB > where ID=XX and Date between mmm and nnn; > > The number of rows in TableA and TableB are different > and EarnA and EarnB are two different data. Now if i > want to show EarnA and EarnB in one query for the same > ID in both Tables, how can i do this? Table schemeas > are simplified for discussion purposes. > > Thanks. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > Try the following SQL statement; SELECT sum(A.EarnA), sum(B.EarnB) FROM TableA A, TableB B WHERE B.id = A.id This is bog standard SQL so I'd suggest you also take a look at a tutorial (http://directory.google.com/Top/Computers/Programming/Languages/SQL/FAQs,_Help,_and_Tutorials/?tc=1) which may provide answers your questions more quickly than this mailing list ;-) Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From chris@cogdon.org Wed Jun 5 03:17:26 2002 From: chris@cogdon.org (Chris Cogdon) Date: Tue, 4 Jun 2002 19:17:26 -0700 Subject: [DB-SIG] Help on this query In-Reply-To: <3CFD7014.7090002@halfcooked.com> References: <20020605004331.43105.qmail@web14704.mail.yahoo.com> <3CFD7014.7090002@halfcooked.com> Message-ID: <200206041917.26013.chris@cogdon.org> On Tuesday 04 June 2002 18:57, Andy Todd wrote: > Titu Kim wrote: > > Hi there, > > I have two unrelated tables A and B which store > > different data. Let say the followings are the table > > schemas, > > > > Table A > > ID number, > > Date number, > > EarnA number > > > > Table B > > ID number, > > Date number, > > EarnB number > > > > ID in Table A and Table B is the same data. Assume > > Date in Table A and Table B is in number format. I can > > get EarnA from Table A with this query > > > > Select sum(EarnA) from TableA > > where ID=3DXX and Date between mmm and nnn; > > > > Similar for TableB i can get EarnB > > Select sum(EarnA) from TableB > > where ID=3DXX and Date between mmm and nnn; > > > > The number of rows in TableA and TableB are different > > and EarnA and EarnB are two different data. Now if i > > want to show EarnA and EarnB in one query for the same > > ID in both Tables, how can i do this? Table schemeas > > are simplified for discussion purposes. > > > > Thanks. > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > Try the following SQL statement; > > SELECT sum(A.EarnA), sum(B.EarnB) > FROM TableA A, TableB B > WHERE B.id =3D A.id > > This is bog standard SQL so I'd suggest you also take a look at a > tutorial > (http://directory.google.com/Top/Computers/Programming/Languages/SQL/FA= Qs,_ >Help,_and_Tutorials/?tc=3D1) > > which may provide answers your questions more quickly than this mailing > list ;-) I don't believe that query will do what he was intending, since it create= s a=20 cross-product over two tables, generating many MANY more rows than was=20 intended, inflating the 'earn' values or even decreasing them if the ID i= n=20 one table is not reflected in the other table. The right solution will depend on what you're trying to do. If you want a= =20 single combined earn value for the summation from both tables, you can cr= eate=20 a 'union' table of all the values, and then sum that. The following examp= le=20 implies your table supports subselects: select sum(earn) from ( select earna as earn from tablea where id=3Dxx an= d=20 date>yy and dateyy and dateyy and date <yy and date . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From kimtitu@yahoo.com Wed Jun 5 04:30:00 2002 From: kimtitu@yahoo.com (Titu Kim) Date: Tue, 4 Jun 2002 20:30:00 -0700 (PDT) Subject: [DB-SIG] Help on this query In-Reply-To: <3CFD7014.7090002@halfcooked.com> Message-ID: <20020605033000.37790.qmail@web14702.mail.yahoo.com> --- Andy Todd wrote: > Titu Kim wrote: > > Hi there, > > I have two unrelated tables A and B which > store > > different data. Let say the followings are the > table > > schemas, > > > > Table A > > ID number, > > Date number, > > EarnA number > > > > Table B > > ID number, > > Date number, > > EarnB number > > > > ID in Table A and Table B is the same data. Assume > > Date in Table A and Table B is in number format. I > can > > get EarnA from Table A with this query > > > > Select sum(EarnA) from TableA > > where ID=XX and Date between mmm and nnn; > > > > Similar for TableB i can get EarnB > > Select sum(EarnA) from TableB > > where ID=XX and Date between mmm and nnn; > > > > The number of rows in TableA and TableB are > different > > and EarnA and EarnB are two different data. Now if > i > > want to show EarnA and EarnB in one query for the > same > > ID in both Tables, how can i do this? Table > schemeas > > are simplified for discussion purposes. > > > > Thanks. > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! - Official partner of 2002 FIFA World Cup > > http://fifaworldcup.yahoo.com > > > > > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > > > Try the following SQL statement; > > SELECT sum(A.EarnA), sum(B.EarnB) > FROM TableA A, TableB B > WHERE B.id = A.id In this query, if they are m row of TableA n row in TableB, each row in TableB will be added m times and each row in TableA will be added n times. This is not what i want. Anyone have idea? > This is bog standard SQL so I'd suggest you also > take a look at a > tutorial > (http://directory.google.com/Top/Computers/Programming/Languages/SQL/FAQs,_Help,_and_Tutorials/?tc=1) > > > which may provide answers your questions more > quickly than this mailing > list ;-) > > Regards, > Andy > -- > ---------------------------------------------------------------------- > From the desk of Andrew J Todd esq - > http://www.halfcooked.com > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From andy47@halfcooked.com Wed Jun 5 04:53:21 2002 From: andy47@halfcooked.com (Andy Todd) Date: Wed, 05 Jun 2002 13:53:21 +1000 Subject: [DB-SIG] Help on this query References: <20020605004331.43105.qmail@web14704.mail.yahoo.com> <3CFD7014.7090002@halfcooked.com> <200206041917.26013.chris@cogdon.org> Message-ID: <3CFD8B31.8080604@halfcooked.com> Chris Cogdon wrote: > On Tuesday 04 June 2002 18:57, Andy Todd wrote: > > >>Titu Kim wrote: >> >>>Hi there, >>> I have two unrelated tables A and B which store >>>different data. Let say the followings are the table >>>schemas, >>> >>>Table A >>>ID number, >>>Date number, >>>EarnA number >>> >>>Table B >>>ID number, >>>Date number, >>>EarnB number >>> >>>ID in Table A and Table B is the same data. Assume >>>Date in Table A and Table B is in number format. I can >>>get EarnA from Table A with this query >>> >>>Select sum(EarnA) from TableA >>>where ID=XX and Date between mmm and nnn; >>> >>>Similar for TableB i can get EarnB >>>Select sum(EarnA) from TableB >>>where ID=XX and Date between mmm and nnn; >>> >>>The number of rows in TableA and TableB are different >>>and EarnA and EarnB are two different data. Now if i >>>want to show EarnA and EarnB in one query for the same >>>ID in both Tables, how can i do this? Table schemeas >>>are simplified for discussion purposes. >>> >>>Thanks. >>> >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Yahoo! - Official partner of 2002 FIFA World Cup >>>http://fifaworldcup.yahoo.com >>> >>> >>>_______________________________________________ >>>DB-SIG maillist - DB-SIG@python.org >>>http://mail.python.org/mailman/listinfo/db-sig >> >>Try the following SQL statement; >> >>SELECT sum(A.EarnA), sum(B.EarnB) >>FROM TableA A, TableB B >>WHERE B.id = A.id >> >>This is bog standard SQL so I'd suggest you also take a look at a >>tutorial >>(http://directory.google.com/Top/Computers/Programming/Languages/SQL/FAQs,_ >>Help,_and_Tutorials/?tc=1) >> >>which may provide answers your questions more quickly than this mailing >>list ;-) > > > I don't believe that query will do what he was intending, since it creates a > cross-product over two tables, generating many MANY more rows than was > intended, inflating the 'earn' values or even decreasing them if the ID in > one table is not reflected in the other table. > > The right solution will depend on what you're trying to do. If you want a > single combined earn value for the summation from both tables, you can create > a 'union' table of all the values, and then sum that. The following example > implies your table supports subselects: > > select sum(earn) from ( select earna as earn from tablea where id=xx and > date>yy and date and date>yy and date > However, if you want to keep the earn values from one table separate from the > earn values from the other, you need a different query: > > select sum(earna), sum(earnb) from ( select earna, null as earnb from tablea > where id=xx and date>yy and date < from tableb where id=2 and date>yy and date > In both cases, you can replace 'joined' with any name. These tested to work > under PostgreSQL. MySQL doesn't support subselects, so you'll have to make do > with either temporary tables, or two queries. > Chris, You are absolutely right, I am an idiot. Mind you, thats some pretty scary SQL you have there and, as you say, it won't work in every database. I've been sitting here scratching my head trying to come up with some ANSI standard SQL that will do the job and failing terribly. Until I thought "hang on, this is Python", so why not write two queries. I'll even put it in a function; def getEarnings(cursor, id, lowDate, highDate): stmt = "SELECT sum(EarnA) FROM TableA WHERE id = %s AND date BETWEEN '%s' AND '%s'" % ( id, lowDate, highDate) cursor.execute(stmt) earnA = cursor.fetchone() stmt = "SELECT sum(EarnB) FROM TableB WHERE id = %s AND date BETWEEN '%s' AND '%s'" % ( id, lowDate, highDate) cursor.execute(stmt) earnB = cursor.fetchone() return (earnA, earnB) Of course, if you want to add the two values together just make the last line read "return earnA+earnB". If you like, you could make the formation of the value of stmt more dynamic, and stick the execute and fetch statements in a seperate function, but this illustrates my point I believe. One final suggestion - don't ever call a column "date" it is usually a reserved word in the RDBMS. Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From chris@cogdon.org Wed Jun 5 05:12:40 2002 From: chris@cogdon.org (Chris Cogdon) Date: Tue, 4 Jun 2002 21:12:40 -0700 Subject: [DB-SIG] Help on this query In-Reply-To: <3CFD8B31.8080604@halfcooked.com> References: <20020605004331.43105.qmail@web14704.mail.yahoo.com> <200206041917.26013.chris@cogdon.org> <3CFD8B31.8080604@halfcooked.com> Message-ID: <200206042112.40116.chris@cogdon.org> On Tuesday 04 June 2002 20:53, Andy Todd wrote: > You are absolutely right, I am an idiot. Mind you, thats some pretty > scary SQL you have there and, as you say, it won't work in every > database. I've been sitting here scratching my head trying to come up > with some ANSI standard SQL that will do the job and failing terribly. Of course, there's lots of stuff you can do in python. However, the fewer= =20 queries you make to the server, and the less information that has to come= =20 back for processing within python, the faster things will go. --=20 ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From andy47@halfcooked.com Wed Jun 5 05:36:26 2002 From: andy47@halfcooked.com (Andy Todd) Date: Wed, 05 Jun 2002 14:36:26 +1000 Subject: [DB-SIG] Help on this query References: <20020605004331.43105.qmail@web14704.mail.yahoo.com> <200206041917.26013.chris@cogdon.org> <3CFD8B31.8080604@halfcooked.com> <200206042112.40116.chris@cogdon.org> Message-ID: <3CFD954A.6090408@halfcooked.com> Chris Cogdon wrote: > On Tuesday 04 June 2002 20:53, Andy Todd wrote: > > >>You are absolutely right, I am an idiot. Mind you, thats some pretty >>scary SQL you have there and, as you say, it won't work in every >>database. I've been sitting here scratching my head trying to come up >>with some ANSI standard SQL that will do the job and failing terribly. > > > Of course, there's lots of stuff you can do in python. However, the fewer > queries you make to the server, and the less information that has to come > back for processing within python, the faster things will go. > > Again true, but beware premature optimisation. For all we know two simple queries and a little bit of Python code are just as efficient as the pure SQL you posted. In fact, in Oracle that would end up in two queries at the server anyway and would probably result in more process cycles to complete (as the intermediate result sets are cached). Contrast that with the overhead of storing two numbers at the client end. The cost of parsing not withstanding, of course. Anyway, its a purely theoretical argument, I just try and follow the tenets of the Pragmatic Programmers (and Uncle Tim) and keep it simple. Ninety nine times out of a hundred the extra cost of having multiple simple SQL statements versus one complex statement are worth it in the time saved developing, debugging and testing. If the simple approach causes a hot spot in your system then by all means optimise, but we shouldn't fuss about it until it *is* a problem. Besides, 99.9997% of database performance problems can be removed by adding an index <0.5 wink> Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From haering_postgresql@gmx.de Wed Jun 5 10:43:56 2002 From: haering_postgresql@gmx.de (Gerhard =?unknown-8bit?Q?H=E4ring?=) Date: Wed, 5 Jun 2002 11:43:56 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released Message-ID: <20020605094356.GC31203@gargamel.hqd-internal> Announce: pyPgSQL - Version 2.1 is released. =========================================================================== pyPgSQL v2.1 has been released. It is a bug fix release to version 2.0, but also includes some enhancements. It is available at http://pypgsql.sourceforge.net. pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. The first module, libpq, exports the PostgreSQL C API to Python. This module is written in C and can be compiled into Python or can be dynamically loaded on demand. The second module, PgSQL, provides the DB-API 2.0 compliant interface and support for various PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This module is written in Python and works with PostgreSQL 7.0 or later and Python 2.0 or later. Note: It is highly recommended that you use PostgreSQL 7.1 or later and Python 2.1 or later. PostgreSQL is a sophisticated Object-Relational DBMS, supporting almost all SQL constructs, including sub-selects, transactions, and user-defined types and functions. It is the most advanced open-source database available any- where More information about PostgreSQL can be found at the PostgreSQL home page at http://www.postgresql.org. Python is an interpreted, interactive, object-oriented programming lang- uage. It combines remarkable power with very clear syntax. It has mod- ules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems (X11, Motif, Tk, Mac, MFC). New builtin modules are easily written in C or C++. Python is also usable as an exten- sion language for applications that need a programmable interface. Python is copyrighted but freely usable and distributable, even for commercial use. More information about Python can be found on the Python home page at http://www.python.org. --------------------------------------------------------------------------- ChangeLog: =========================================================================== Changes since pyPgSQL Version 2.0 ================================= pyPgSQL 2.1 is now compatible and tested to work with PostgreSQL 7.2.x. Changes to README ----------------- * Added documentation for the new TransactionLevel attribute of the Connection object. Changes to PgSQL.py ------------------- * Added code to implement support for setting PostgreSQL transaction levels. [Feature Request #481727]. * Got rid of redundant building and storing of the mapping of column names to column positions in the PgResultSet class. Now, rows of the same query are instances of a dynamically created class, which has this mapping as a class attribute instead of an attribute of the instance. This saves a lot of space, and also slightly increases performance of cursor fetches. * Fixed the array parsing so it also works with PostgreSQL versions 7.2.x. The PostgreSQL developers changed the quoting in the string representation of arrays in 7.2 beta cycle: strings are now only quoted when otherwise the array representation would be ambiguous. The new parseArray() method should handle the old and new way of quoting in arrays. [Bug #539769]. Also added a new testcase for the ARRAY type. * Improved the array parsing, so that it now passes all the new mean testcases. Added support for parsing multidimensional arrays. Eventually, the array parsing code should go as a support function into libpq. * Replaced all typechecks with "is" operators instead of equals. Mark McEahern had a problem with using pyPgSQL in combination with a FixedPoint class where the reason was that the FixedPoint class was not comarable to None. The consensus on python-list was that None and all types are singletons, so they should be checked using "is", which is also faster, because it only checks for object identity. * Fixed a couple of problems found by Steven D. Arnold: 1. A undefined variable was used in a few places where notices were popped from the notice list. 2. Comparisons between 2 PgNumerics gave the wrong result. * Fixed problem that occurs when the sum() aggregate returns a NULL. [Bug #505162]. Changes to pgversion.c ---------------------- * Allow for development and beta versions of PostgreSQL Changes to libpqmodule.c ------------------------ * Removed special escaping of control characters in arrays. * Added support for two missing OID types: aclitem and macaddr. * Applied patch by Chris Bainbridge [Patch #505941] "fix for null bytes in bytea". Changes to pgresult.c --------------------- * Change the point at which an OID is tested to see if it is a Large Object from 1700 to 16383. From jose@sferacarta.com Thu Jun 6 09:44:54 2002 From: jose@sferacarta.com (jose) Date: Thu, 06 Jun 2002 10:44:54 +0200 Subject: [DB-SIG] Installing MySQL-python on python 2.2 References: Message-ID: <3CFF2106.2030903@sferacarta.com> Please someone tell me how to unsubscibe? tankx From andy@dustman.net Thu Jun 6 14:30:21 2002 From: andy@dustman.net (Andy Dustman) Date: 06 Jun 2002 09:30:21 -0400 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <20020605094356.GC31203@gargamel.hqd-internal> References: <20020605094356.GC31203@gargamel.hqd-internal> Message-ID: <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> On Wed, 2002-06-05 at 05:43, Gerhard H=E4ring wrote: > pyPgSQL v2.1 has been released. It is a bug fix release to version 2.0, b= ut > also includes some enhancements. I'm curious... There are at least two actively maintained PostgreSQL interfaces (three if you count the one that comes with PostgreSQL). I've personally used psycopg a bit lately. What are the advantages and disadvantages of the various interfaces? --=20 Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all that I yam." -- Popeye From r.taylor@eris.qinetiq.com Thu Jun 6 14:32:09 2002 From: r.taylor@eris.qinetiq.com (Richard Taylor) Date: Thu, 6 Jun 2002 14:32:09 +0100 Subject: [DB-SIG] Is there a better way of doing this? Message-ID: <200206061432.11662.r.taylor@eris.qinetiq.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am new to this list so forgive me if this subject has been done to death. I have been through the list archives and although the issues surrounding the API of 'rowcount' have been discussed my problem has not really been addressed. I have been troubled by one aspect of DBI connections for a while, I don't like the way that I check if rows have been returned from a query or not. I am about to try to draft an article on accessing a database from python for the ACCU journal and I don't want to look a prat when someone points out the obviously crass way that I am doing this. So can anyone suggest a better way? The problem is that from the DBI v2.0 spec (below) "rowcount" cannot be relied upon (as previous theads have discussed). """rowcount This read-only attribute specifies the number of rows that the last executeXXX() produced (for DQL statements like select) or affected (for DML statements like update or insert). The attribute is -1 in case no executeXXX() has been performed on the cursor or the rowcount of the last operation is not determinable by the interface.[7] """ This appears to mean that if "rowcount == -1" you have to just go ahead and call one of the "fetch" functions and catch any exception that is raised. This is not too bad except that which exception is raised for "no rows to fetch" is not defined in the spec. The "fetch" functions are defined to raise a "subclass of Error" but that includes a number of errors that the DBI library can raise. There is no specific "no rows to fetch" exception. The only implementation I can see is to check the "value" field of the Error exception to determine if "no rows to fetch" was the cause of the exception or not. This is bad because the DBI does not specify the syntax of the "value" fields of the Error exception. In my experience each DBI implementation chooses its own which are often different (e.g popy used "No more results to fetch" but psycopg uses "no results to fetch"). The upshot of all of this is that I can not see how to write the following code in a way that will work across different DBI implementations. try: cr=self.cursor() cr.execute (query) self.commit() # Trap selects that return nothing. if cr.rowcount == 0 : return None q=cr.fetchall() cr.close() log.debug('query done: and we got a result') except psycopg.Error, x: type, value = sys.exc_info()[:2] if str(value)=='no results to fetch': # this is specific to psycopg log.debug('query done: but there was no result to fetch') q = None else: log.error("""DB Query failed with psycopg.Error: %s DB Query was: %s""" % (value,query)) q = None I understand from the previous threads why 'rowcount' cannot be relied upon. I think that it would be useful if a specific subclass of Error could be defined for the "no rows to fetch" case and the DBI spec require implementations to raise this error from the "fetch" functions, rather than just any subclass of Error or Error. This would enable a script to be portable across DBI implementations (at least in this regard). I would be grateful for any other suggestions for how to write the above code in a way that did not require a backend specific check. Richard - -- QinetiQ B105 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8/2Ra7Z7YaKfan9kRAhQDAKCr5P4CVBRhdAlzadwNkUe7OEP6aACgp823 +PMFaAMko35AWLaRu+62SnM= =aXLO -----END PGP SIGNATURE----- From fog@initd.org Thu Jun 6 14:44:11 2002 From: fog@initd.org (Federico Di Gregorio) Date: 06 Jun 2002 15:44:11 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> References: <20020605094356.GC31203@gargamel.hqd-internal> <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> Message-ID: <1023371051.11496.74.camel@nenya> --=-MFBwxJCJANuLZIp/PUqS Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il gio, 2002-06-06 alle 15:30, Andy Dustman ha scritto: > On Wed, 2002-06-05 at 05:43, Gerhard H=E4ring wrote: > > pyPgSQL v2.1 has been released. It is a bug fix release to version 2.0,= but > > also includes some enhancements. >=20 > I'm curious... There are at least two actively maintained PostgreSQL > interfaces (three if you count the one that comes with PostgreSQL). I've > personally used psycopg a bit lately. What are the advantages and > disadvantages of the various interfaces? i think this question risks to start a flame but.. i think the main difference between pyPgSQL and psycopg is that the first is built in two layers (python bindings to libpq and dbapi module over it) while psycopg does everything in pure C and in a single module (that's because psycopg was designed for speed). i won't say one's better than the other. they take different approaches and (for what i know about pyPgSQL) they both are good drivers, supported and reliable.=20 now something about psycopg: psycopg 1.0.8 has proven to be really fast and it always release the global lock before any time-consuming task, because it was born for multi-threaded applications. it is also very stable and used in some large production environments. it includes support for user-defined typecasting objects (you can write your own in python and have them convert postfres types for you, that's how the zpygresDA layer has been implemented). psucopg 1.1 (development branch) supports for async queries (you can mix both dbapi sync queries and async ones using the same api), notifies, copy to/copy from and other postgresql specific stuff. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org A short story: I want you. I love you. I'll miss you. -- Me --=-MFBwxJCJANuLZIp/PUqS Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA8/2crvcCgrgZGjesRAr2aAJwIIhvo6AjB7WwrtiLByTg8gl0tdgCgyiUl v4UkIJnCO8g6Ntk37Gfubto= =f4Op -----END PGP SIGNATURE----- --=-MFBwxJCJANuLZIp/PUqS-- From kjcole@gri.gallaudet.edu Thu Jun 6 14:34:03 2002 From: kjcole@gri.gallaudet.edu (Kevin Cole) Date: Thu, 6 Jun 2002 09:34:03 -0400 (EDT) Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <1023371051.11496.74.camel@nenya> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Does anyone know if psycopg is available as an RPM that works well with the Red Hat's PostGreSQL RPM's? Since I *LIKE* databases, I strongly prefer to have all the toys I install set up as RPM's rather than straight tarballs, cuz it does a really nice job of keeping track of things. I even had the beginnings of a nice little RPM to PostGreSQL converter at one time... (Never used .deb's, but someday I probably will.) On 6 Jun 2002, Federico Di Gregorio wrote: > i think this question risks to start a flame but.. i think the main > difference between pyPgSQL and psycopg is that the first is built in two > layers (python bindings to libpq and dbapi module over it) while psycopg > does everything in pure C and in a single module (that's because psycopg > was designed for speed). > > now something about psycopg: psycopg 1.0.8 has proven to be really fast > and it always release the global lock before any time-consuming task, > because it was born for multi-threaded applications. it is also very > stable and used in some large production environments. it includes > support for user-defined typecasting objects (you can write your own in > python and have them convert postfres types for you, that's how the > zpygresDA layer has been implemented). > > psucopg 1.1 (development branch) supports for async queries (you can mix > both dbapi sync queries and async ones using the same api), notifies, > copy to/copy from and other postgresql specific stuff. - -- Kevin Cole, RHCE, Linux Admin | E-mail: kjcole@gri.gallaudet.edu Gallaudet Research Institute | WWW: http://gri.gallaudet.edu/~kjcole/ Hall Memorial Bldg S-419 | Voice: (202) 651-5135 Washington, D.C. 20002-3695 | FAX: (202) 651-5746 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8/2TUh8702ObzMscRAihDAJ4oaOfCMK2WfvE9zAE4CU/iRuWNzgCgqAJE mdyZ5zDHPxe619KZ1Giz7tY= =K1/g -----END PGP SIGNATURE----- From fog@initd.org Thu Jun 6 15:00:00 2002 From: fog@initd.org (Federico Di Gregorio) Date: 06 Jun 2002 16:00:00 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: References: Message-ID: <1023372000.11498.90.camel@nenya> --=-AxmJ9bjZnnCYEBW3qK7D Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il gio, 2002-06-06 alle 15:34, Kevin Cole ha scritto: > Does anyone know if psycopg is available as an RPM that works well with > the Red Hat's PostGreSQL RPM's? Since I *LIKE* databases, I strongly > prefer to have all the toys I install set up as RPM's rather than > straight tarballs, cuz it does a really nice job of keeping track of > things. I even had the beginnings of a nice little RPM to PostGreSQL > converter at one time... (Never used .deb's, but someday I probably > will.) psycopg tarball includes an rpm spec file sent in by a kind user. i would be glad if someone can use that spec file after each release and send me rpm packages, so that i can put them on the download page. (but maybe, those psycopg-specific stuff is better discussed on the psycopg ML, or not? :)=20 --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org All'inizio ho scritto un programma proprietario, in esclusiva per il cliente; =E8 stato tristissimo, perch=E8 mi ha succhiato un pezzo di anima. -- Alessandro Rubini --=-AxmJ9bjZnnCYEBW3qK7D Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA8/2rgvcCgrgZGjesRAlXXAJ0TfrAOjMLmHBbaztNLGWuQKtKNwQCePf1L ESJgH1/tEb+ViKRvS5pzfow= =nxHA -----END PGP SIGNATURE----- --=-AxmJ9bjZnnCYEBW3qK7D-- From wilk@flibuste.net Thu Jun 6 15:26:23 2002 From: wilk@flibuste.net (William Dode) Date: Thu, 6 Jun 2002 16:26:23 +0200 Subject: [DB-SIG] MSAccess Message-ID: <20020606162623.066f9cdd.wilk@flibuste.net> hi, What is the best way (most stable) to use an msaccess database ? The odbc driver seems has no support, but since i use it i had never any problems but i did'nt use in production... I found a page about ADO http://www.e-coli.net/pyado.html, it seems to work well also... i think it could be easy to make a DB2api around it isnt'it ? bye -- William Dodé - Informaticien Indépendant http://www.flibuste.net From matt@zope.com Thu Jun 6 15:26:59 2002 From: matt@zope.com (Matthew T. Kromer) Date: Thu, 06 Jun 2002 10:26:59 -0400 Subject: [DB-SIG] Is there a better way of doing this? References: <200206061432.11662.r.taylor@eris.qinetiq.com> Message-ID: <3CFF7133.6030303@zope.com> Richard Taylor wrote: >[...] > >This appears to mean that if "rowcount == -1" you have to just go ahead and >call one of the "fetch" functions and catch any exception that is raised. >This is not too bad except that which exception is raised for "no rows to >fetch" is not defined in the spec. The "fetch" functions are defined to raise >a "subclass of Error" but that includes a number of errors that the DBI >library can raise. There is no specific "no rows to fetch" exception. The >only implementation I can see is to check the "value" field of the Error >exception to determine if "no rows to fetch" was the cause of the exception >or not. > > It seems to me fetch should actually return an empty set when it cannot fetch more records, and the application should check for a zero-length return set. Arguably, I violate the DB 2.0 API spec by doing this in DCOracle2. DCOracle2 also updates the rowcount as records are retrieved, but that also makes it arguably worse; any logic that performed its OWN count and compared that to the rowcount attribute would decide that all the results were present immediately. >This is bad because the DBI does not specify the syntax of the "value" fields >of the Error exception. In my experience each DBI implementation chooses its >own which are often different (e.g popy used "No more results to fetch" but >psycopg uses "no results to fetch"). The upshot of all of this is that I can >not see how to write the following code in a way that will work across >different DBI implementations. > >[...] > I am rather strongly opposed to trying to over-genericize error returns. Oracle has an error code space of thousands of error messages. Granted, only a few mean "no records available" but if the vendor doesn't categorize errors by type, it is not reasonable to expect the DB API driver to do so. Granted, you're not arguing for that, but I've already stated that I think the way to handle "no more results" is to return a zero length result. Note that "no more results" is also different from "no results generated." Oracle is also one of those databases that doesn't tell you how many records are in a result set up front; you have to pull them all and count as you go. Is that frustrating? Yes, certainly. But an application that retrieves all the records in order to count them will have done so explicitly; with the corresponding penalty in performance. By the same token, this is why you cannot also expect the values of errors to be consistent -- the values should reflect what the underlying database returns, and not some intermediate interpretation by the adapter. That's not a very good thing to hear from the application programmer's point of view; but as an adapter author, I'll assert that there are plenty of database dependant things you can do within the bounds of the API right now. Look at the mess of how to determine parameter binding styles. Applications are nominally expected to be able to adapt to about 5 different styles of parameter binding; it would be much easier if the adapter and the application could negotiate on the binding style. -- Matt Kromer Zope Corporation http://www.zope.com/ From fog@initd.org Thu Jun 6 15:36:02 2002 From: fog@initd.org (Federico Di Gregorio) Date: 06 Jun 2002 16:36:02 +0200 Subject: [DB-SIG] Is there a better way of doing this? In-Reply-To: <3CFF7133.6030303@zope.com> References: <200206061432.11662.r.taylor@eris.qinetiq.com> <3CFF7133.6030303@zope.com> Message-ID: <1023374163.11498.123.camel@nenya> --=-2o7ijsTeoOHY6nXnffMw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il gio, 2002-06-06 alle 16:26, Matthew T. Kromer ha scritto: [super snip] > It seems to me fetch should actually return an empty set when it cannot=20 > fetch more records, and the application should check for a zero-length=20 > return set. Arguably, I violate the DB 2.0 API spec by doing this in=20 > DCOracle2. he's trying to write a generalized function that can be used to execute queries and return results if present. i think the dbapi specifies that after a SELECT an empty set can be returned by the fetchXXX functions but an exception is raised if the query was not a SELECT. you can trust rowcount because it can be >0 after any query (not only SELECT). a solution that can be used on psycopg is to test the .description attribute; it is a tuple after a SELECT and None in any other case, but I don't know if that is portable. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org The devil speaks truth much oftener than he's deemed. He has an ignorant audience. -- Byron (suggested by Alice Fontana) --=-2o7ijsTeoOHY6nXnffMw Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA8/3NSvcCgrgZGjesRAo5kAKCC2U5Qw0Mj//VgwmZTzQZeqRj4nwCfeyuu buhNjKERwuSve5VWoB3g3oQ= =YAU+ -----END PGP SIGNATURE----- --=-2o7ijsTeoOHY6nXnffMw-- From r.taylor@eris.qinetiq.com Thu Jun 6 15:55:52 2002 From: r.taylor@eris.qinetiq.com (Richard Taylor) Date: Thu, 6 Jun 2002 15:55:52 +0100 Subject: [DB-SIG] Is there a better way of doing this? In-Reply-To: <3CFF7133.6030303@zope.com> References: <200206061432.11662.r.taylor@eris.qinetiq.com> <3CFF7133.6030303@zope.com> Message-ID: <200206061556.02763.r.taylor@eris.qinetiq.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 06 June 2002 3:26 pm, Matthew T. Kromer wrote: >>[...] > It seems to me fetch should actually return an empty set when it cannot > fetch more records, and the application should check for a zero-length > return set. Arguably, I violate the DB 2.0 API spec by doing this in > DCOracle2. > DCOracle2 also updates the rowcount as records are retrieved, but that > also makes it arguably worse; any logic that performed its OWN count and > compared that to the rowcount attribute would decide that all the > results were present immediately. > - From a humble DB API users perspective having the fetch functions return a zero-length return set would be fine. It would enable sensible code where an "exception" meant just that and no DB specific code would be required. > >[...] > > I am rather strongly opposed to trying to over-genericize error returns. > Oracle has an error code space of thousands of error messages. > Granted, only a few mean "no records available" but if the vendor > doesn't categorize errors by type, it is not reasonable to expect the DB > API driver to do so. Granted, you're not arguing for that, but I've > already stated that I think the way to handle "no more results" is to > return a zero length result. > I can see your point. I would only argue for a specific exception for "no more records" if your option of a zero length result set was not taken up. Mapping real exceptions onto a DB-API subset would be a bad idea. > > Note that "no more results" is also different from "no results generated." > Indeed, although this distinction would be lost by a zero length result approach. > > Oracle is also one of those databases that doesn't tell you how many > records are in a result set up front; you have to pull them all and > count as you go. Is that frustrating? Yes, certainly. But an > application that retrieves all the records in order to count them will > have done so explicitly; with the corresponding penalty in performance. > I have no problem with not knowing how many results rows there are, all I want is a portable way of know whether there are any results rows and I don't mind calling fetch to find out. > > By the same token, this is why you cannot also expect the values of > errors to be consistent -- the values should reflect what the underlying > database returns, and not some intermediate interpretation by the > adapter. That's not a very good thing to hear from the application > programmer's point of view; but as an adapter author, I'll assert that > there are plenty of database dependant things you can do within the > bounds of the API right now. Look at the mess of how to determine > parameter binding styles. Applications are nominally expected to be > able to adapt to about 5 different styles of parameter binding; it would > be much easier if the adapter and the application could negotiate on the > binding style. I think you are absolutely right about passing on the underlying database errors. All you can usually do with unexpected exceptions is log them somewhere and try to recover. It then becomes very important that what is logged in useful and only the root DB error information is going to help with debugging. I also agree that DB dependant functionality should be allow and expected. Indeed we make use of Postgres specific functionality ourselves. However, the simple action of making a query and fetching the results seams to me to be so fundamental to every application that it should be portable. What is the opposition to the zero return set option? Richard - -- QinetiQ B105 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8/3gA7Z7YaKfan9kRAvPPAJ40hImIMGpikpJJuN+S7cEXpiUvpACeKi4w eNoXcF+EZuCwQUlwsBgqxRM= =g26A -----END PGP SIGNATURE----- From matt@zope.com Thu Jun 6 16:20:19 2002 From: matt@zope.com (Matthew T. Kromer) Date: Thu, 06 Jun 2002 11:20:19 -0400 Subject: [DB-SIG] Is there a better way of doing this? References: <200206061432.11662.r.taylor@eris.qinetiq.com> <3CFF7133.6030303@zope.com> <200206061556.02763.r.taylor@eris.qinetiq.com> Message-ID: <3CFF7DB3.6000002@zope.com> Richard Taylor wrote: >I think you are absolutely right about passing on the underlying database >errors. All you can usually do with unexpected exceptions is log them >somewhere and try to recover. It then becomes very important that what is >logged in useful and only the root DB error information is going to help with >debugging. > >I also agree that DB dependant functionality should be allow and expected. >Indeed we make use of Postgres specific functionality ourselves. However, the >simple action of making a query and fetching the results seams to me to be so >fundamental to every application that it should be portable. > >What is the opposition to the zero return set option? > >Richard > > Well, I just checked what DCOracle2 does on a fetch after insert. It raises a ProgrammingError, because fetch is invalid after insert. I didn't notice before because I didn't look deeply into the C code, only at the python layer. When results are exhausted for fetchone() it returns None, for fetchmany() and fetchall() it returns []. I do *not* assert that this is the correct behavior. It's been a while since I poked around in the guts of the return mechanism (like maybe 18 months ). Like Frederico Di Gregorio mentioned regarding psycopg, I also set the description attribute to None if there is no description available after an execute(). This is probably the *best* way to determine if results are expected to be available, rather than trying to fetch them and failing. Unfortunately I am not aware of any DB API conformance testing suite. As an adapter author, I've written tests, but they're all subject to my interpretation of the rules. If anyone has an API testing suite I'd be glad to either: 1) Change DCOracle2 to pass any tests that fail, or 2) Argue vociferously that the interpretation that the test was based on was flawed . -- Matt Kromer Zope Corporation http://www.zope.com/ From jacobs@penguin.theopalgroup.com Thu Jun 6 16:35:42 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Thu, 6 Jun 2002 11:35:42 -0400 (EDT) Subject: [DB-SIG] Is there a better way of doing this? In-Reply-To: <3CFF7DB3.6000002@zope.com> Message-ID: On Thu, 6 Jun 2002, Matthew T. Kromer wrote: > Unfortunately I am not aware of any DB API > conformance testing suite. As an adapter author, I've written tests, > but they're all subject to my interpretation of the rules. Funny you should ask -- I'm working on just such a beast. My company maintains a fairly powerful database abstraction layer for Python, and I am working on open-sourcing it, along with our generic test suite. It doesn't claim to test _everything_ related to the DB-API 2.0 spec, though we do a fairly extensive set. Once its open sourced, I'm sure that it could be extended by the community to do so. Regards, -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From fog@initd.org Thu Jun 6 16:41:33 2002 From: fog@initd.org (Federico Di Gregorio) Date: 06 Jun 2002 17:41:33 +0200 Subject: [DB-SIG] Is there a better way of doing this? In-Reply-To: <3CFF7DB3.6000002@zope.com> References: <200206061432.11662.r.taylor@eris.qinetiq.com> <3CFF7133.6030303@zope.com> <200206061556.02763.r.taylor@eris.qinetiq.com> <3CFF7DB3.6000002@zope.com> Message-ID: <1023378094.11496.149.camel@nenya> --=-a+aNEw7LJjPMHMZsa1S0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il gio, 2002-06-06 alle 17:20, Matthew T. Kromer ha scritto: > Well, I just checked what DCOracle2 does on a fetch after insert. It=20 > raises a ProgrammingError, because fetch is invalid after insert. I=20 > didn't notice before because I didn't look deeply into the C code, only=20 > at the python layer. >=20 > When results are exhausted for fetchone() it returns None, for=20 > fetchmany() and fetchall() it returns []. >=20 > I do *not* assert that this is the correct behavior. It's been a while=20 > since I poked around in the guts of the return mechanism (like maybe 18=20 > months ). AFAIK, this is The Right Behavior (TM) as per DBAPI-2.0 document. > Like Frederico Di Gregorio mentioned regarding psycopg, I also set the=20 > description attribute to None if there is no description available after=20 > an execute(). This is probably the *best* way to determine if results=20 > are expected to be available, rather than trying to fetch them and failin= g. >=20 > Unfortunately I am not aware of any DB API=20 > conformance testing suite. As an adapter author, I've written tests,=20 me and thierry michel (of PoPy fame), we are writing one using pyunit. a very preliminary version can be reached at the url given below. (we had announced it in a week or so, but, alas, you hooked me into it...) there are some serious problems in testing the functionality of a db adapter when you should used the methods you're testing (how can i rollback() a failed test if rollback does not work?) so expect heavy posting from us in the future ;) http://initd.org/pub/software/paco/paco-snapshot-20020606.tar.gz --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Qu'est ce que la folie? Juste un sentiment de libert=E9 si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra --=-a+aNEw7LJjPMHMZsa1S0 Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA8/4KsvcCgrgZGjesRAszgAJ4q5H4hH2afl18+NXP8pWwb2y69FgCfYlph vwH3rhGNR6wKp0nGDrKyXYY= =4Oe8 -----END PGP SIGNATURE----- --=-a+aNEw7LJjPMHMZsa1S0-- From gerhard@bigfoot.de Thu Jun 6 16:52:44 2002 From: gerhard@bigfoot.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Thu, 6 Jun 2002 17:52:44 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: References: <1023371051.11496.74.camel@nenya> Message-ID: <20020606155244.GA3057@lilith.my-fqdn.de> * Kevin Cole [2002-06-06 09:34 -0400]: > Does anyone know if psycopg is available as an RPM that works well with > the Red Hat's PostGreSQL RPM's? This isn't what you asked for, but for database interfaces that are built using distutils, like pyPgSQL, you can simply issue: $ python setup.py bdist_rpm to create a RPM. The psycopg developers will likely have a reason for not using distutils in the first place. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From fog@initd.org Thu Jun 6 17:03:01 2002 From: fog@initd.org (Federico Di Gregorio) Date: 06 Jun 2002 18:03:01 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <20020606155244.GA3057@lilith.my-fqdn.de> References: <1023371051.11496.74.camel@nenya> <20020606155244.GA3057@lilith.my-fqdn.de> Message-ID: <1023379382.11498.162.camel@nenya> --=-cQ0qPvbHoM5gDW8wvD6b Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il gio, 2002-06-06 alle 17:52, Gerhard H=E4ring ha scritto: > * Kevin Cole [2002-06-06 09:34 -0400]: > > Does anyone know if psycopg is available as an RPM that works well with > > the Red Hat's PostGreSQL RPM's? >=20 > This isn't what you asked for, but for database interfaces that are > built using distutils, like pyPgSQL, you can simply issue: >=20 > $ python setup.py bdist_rpm >=20 > to create a RPM. The psycopg developers will likely have a reason for > not using distutils in the first place. i would like to switch to distutils but currently i have the following problem: psycopg compiles and run on many different archs (ia32, ia64, sparc, powerpc, m68k, alpha, etc.) and platforms (linux, *bsd, macos x, sun solaris and win32). apart from win32, still not perfectly integrated, all the others depend on a single configure.in script about 50 lines in length. do distutils allow for that? do they provide an easy way to: * check for libraries * check for headers * check for functions in libraries * define variables used at compile time if someone can show me a 50 liners setup.py script that does all that, i'll be glad to switch. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Qu'est ce que la folie? Juste un sentiment de libert=E9 si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra --=-cQ0qPvbHoM5gDW8wvD6b Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA8/4e1vcCgrgZGjesRAs87AKCsIDtRL9l6o2prsVMdEviTnzm5OQCg00of M0DP1xgQLsT3DM6eVid0XfY= =RDu8 -----END PGP SIGNATURE----- --=-cQ0qPvbHoM5gDW8wvD6b-- From jwilhelm@outsourcefinancial.com Thu Jun 6 17:08:05 2002 From: jwilhelm@outsourcefinancial.com (Joseph Wilhelm) Date: 06 Jun 2002 09:08:05 -0700 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> References: <20020605094356.GC31203@gargamel.hqd-internal> <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> Message-ID: <1023379685.4424.2.camel@jwilhelm.ofsloans.com> On Thu, 2002-06-06 at 06:30, Andy Dustman wrote: > I'm curious... There are at least two actively maintained PostgreSQL > interfaces (three if you count the one that comes with PostgreSQL). I've > personally used psycopg a bit lately. What are the advantages and > disadvantages of the various interfaces? Another bit of curiosity... do either of these interfaces support dictionary results? I'm currently using the 'pg' module provided with the PostgreSQL distribution primarily for the fact that I have need of dictionary results, and pg gladly supplies them. However, if one of these is "better", and provides me with dicts, I would love to give it a shot. --Joseph Wilhelm From haering_postgresql@gmx.de Thu Jun 6 17:16:54 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Thu, 6 Jun 2002 18:16:54 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <1023379685.4424.2.camel@jwilhelm.ofsloans.com> References: <20020605094356.GC31203@gargamel.hqd-internal> <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> <1023379685.4424.2.camel@jwilhelm.ofsloans.com> Message-ID: <20020606161654.GD3057@lilith.my-fqdn.de> * Joseph Wilhelm [2002-06-06 09:08 -0700]: > On Thu, 2002-06-06 at 06:30, Andy Dustman wrote: > > > I'm curious... There are at least two actively maintained PostgreSQL > > interfaces (three if you count the one that comes with PostgreSQL). I've > > personally used psycopg a bit lately. What are the advantages and > > disadvantages of the various interfaces? > > > Another bit of curiosity... do either of these interfaces support > dictionary results? I'm currently using the 'pg' module provided with > the PostgreSQL distribution primarily for the fact that I have need of > dictionary results, and pg gladly supplies them. However, if one of > these is "better", and provides me with dicts, I would love to give it a > shot. I'm pretty sure both are way better than PyGreSQL, but I'm probably a little biased because I once got bitten badly by PyGreSQL bug. For pyPgSQL, just use the normal fetch methods: these return instances of PgResultSet, which you can use in three different ways: cursor.execute("select foo from bar") res = cursor.fetchone() print res[0] # DB-API standard print res["foo"] # dictionary-like print res.foo # attribute-access You can switch off this nonstandard behaviour if you want by setting PgSQL.fetchReturnsList to 1. In psycopg, use the various dictfetchXXX functions. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From fog@initd.org Thu Jun 6 17:18:58 2002 From: fog@initd.org (Federico Di Gregorio) Date: 06 Jun 2002 18:18:58 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <1023379685.4424.2.camel@jwilhelm.ofsloans.com> References: <20020605094356.GC31203@gargamel.hqd-internal> <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> <1023379685.4424.2.camel@jwilhelm.ofsloans.com> Message-ID: <1023380339.11498.169.camel@nenya> --=-7U/la3NdMoNJ6aeTr5E/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il gio, 2002-06-06 alle 18:08, Joseph Wilhelm ha scritto: > On Thu, 2002-06-06 at 06:30, Andy Dustman wrote: > =20 > > I'm curious... There are at least two actively maintained PostgreSQL > > interfaces (three if you count the one that comes with PostgreSQL). I'v= e > > personally used psycopg a bit lately. What are the advantages and > > disadvantages of the various interfaces? > >=20 > Another bit of curiosity... do either of these interfaces support > dictionary results? I'm currently using the 'pg' module provided with > the PostgreSQL distribution primarily for the fact that I have need of > dictionary results, and pg gladly supplies them. However, if one of > these is "better", and provides me with dicts, I would love to give it a > shot. erm. psycopg has dictfetchXXX methods. but i think is much better implement them in python-space, if you really use them a lot. (for example, if you have two columns with the same name, psycopg will happily overwrite the first one with the second.) --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Quis custodiet ipsos custodes? -- Juvenal, Satires, VI, 347 --=-7U/la3NdMoNJ6aeTr5E/ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA8/4tyvcCgrgZGjesRAoNyAJ4vtnV7PTd7X0oE2XDtRGF4b7yDgwCgyfPX O0OMGlB1qEqTOIqTkj/Ele0= =lt9V -----END PGP SIGNATURE----- --=-7U/la3NdMoNJ6aeTr5E/-- From haering_postgresql@gmx.de Thu Jun 6 17:29:53 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Thu, 6 Jun 2002 18:29:53 +0200 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <1023380339.11498.169.camel@nenya> References: <20020605094356.GC31203@gargamel.hqd-internal> <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> <1023379685.4424.2.camel@jwilhelm.ofsloans.com> <1023380339.11498.169.camel@nenya> Message-ID: <20020606162953.GA3167@lilith.my-fqdn.de> * Federico Di Gregorio [2002-06-06 18:18 +0200]: > erm. psycopg has dictfetchXXX methods. but i think is much better > implement them in python-space, if you really use them a lot. (for > example, if you have two columns with the same name, psycopg will > happily overwrite the first one with the second.) Probably best to raise ProgrammingError("don't use SELECT * damnit, and go look about\ AS in your SQL book") ;-) Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From haering_postgresql@gmx.de Thu Jun 6 17:35:11 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Thu, 6 Jun 2002 18:35:11 +0200 Subject: [DB-SIG] MSAccess In-Reply-To: <20020606162623.066f9cdd.wilk@flibuste.net> References: <20020606162623.066f9cdd.wilk@flibuste.net> Message-ID: <20020606163511.GA3187@lilith.my-fqdn.de> * William Dode [2002-06-06 16:26 +0200]: > I found a page about ADO http://www.e-coli.net/pyado.html, it seems > to work well also... i think it could be easy to make a DB2api > around it isnt'it ? Relatively easy, but it's some work to make it DB-API compliant. We're currently experiencing that in the PySQLite project: it's relatively easy to get something out the door, but a lot more work lies in the refinements. Btw. I've saved the following email that I could send you: From: Michel Orengo To: python-list@python.org Subject: [ANN]pre-release DBAPI2.0 for ADO Date: Wed, 5 Jul 2000 13:26:41 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) if you found it useful. Looks like it never got finished. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From wilk@flibuste.net Thu Jun 6 17:58:43 2002 From: wilk@flibuste.net (William Dode) Date: Thu, 6 Jun 2002 18:58:43 +0200 Subject: [DB-SIG] MSAccess In-Reply-To: <20020606163511.GA3187@lilith.my-fqdn.de> References: <20020606162623.066f9cdd.wilk@flibuste.net> <20020606163511.GA3187@lilith.my-fqdn.de> Message-ID: <20020606185843.4e81fede.wilk@flibuste.net> Le Thu, 6 Jun 2002 18:35:11 +0200 Gerhard Häring écrivait: > * William Dode [2002-06-06 16:26 +0200]: > > I found a page about ADO http://www.e-coli.net/pyado.html, it seems > > to work well also... i think it could be easy to make a DB2api > > around it isnt'it ? > > Relatively easy, but it's some work to make it DB-API compliant. We're > currently experiencing that in the PySQLite project: it's relatively > easy to get something out the door, but a lot more work lies in the > refinements. I imagine that it can be not so easy to do a complet db-api compliant modules, but i want to be sure first that it can be interesting... What does zope use for odbc connection for example ? thanks for the email, i will contact him. bye > > Btw. I've saved the following email that I could send you: > > From: Michel Orengo > To: python-list@python.org > Subject: [ANN]pre-release DBAPI2.0 for ADO > Date: Wed, 5 Jul 2000 13:26:41 -0500 > X-Mailer: Internet Mail Service (5.5.2653.19) > > if you found it useful. Looks like it never got finished. > > Gerhard > -- > mail: gerhard bigfoot de registered Linux user #64239 > web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id > AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B > 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda > x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- William Dodé - Informaticien Indépendant http://www.flibuste.net From mal@lemburg.com Thu Jun 6 18:44:12 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 06 Jun 2002 19:44:12 +0200 Subject: [DB-SIG] MSAccess References: <20020606162623.066f9cdd.wilk@flibuste.net> Message-ID: <3CFF9F6C.6070403@lemburg.com> William Dode wrote: > hi, > > What is the best way (most stable) to use an msaccess database ? > > The odbc driver seems has no support, but since i use it i had > never any problems but i did'nt use in production... If you want a supported DB-API2 compatible interface, you should have a look at our mxODBC package for Python. It supports MS Access and even allows storing and fetching Unicode. > I found a page about ADO http://www.e-coli.net/pyado.html, it seems > to work well also... i think it could be easy to make a DB2api > around it isnt'it ? > > bye > -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From andy@dustman.net Thu Jun 6 18:54:20 2002 From: andy@dustman.net (Andy Dustman) Date: 06 Jun 2002 13:54:20 -0400 Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <20020606162953.GA3167@lilith.my-fqdn.de> References: <20020605094356.GC31203@gargamel.hqd-internal> <1023370221.13820.10.camel@4.0.0.10.in-addr.arpa> <1023379685.4424.2.camel@jwilhelm.ofsloans.com> <1023380339.11498.169.camel@nenya> <20020606162953.GA3167@lilith.my-fqdn.de> Message-ID: <1023386060.13820.39.camel@4.0.0.10.in-addr.arpa> On Thu, 2002-06-06 at 12:29, Gerhard H=E4ring wrote: > * Federico Di Gregorio [2002-06-06 18:18 +0200]: > > erm. psycopg has dictfetchXXX methods. but i think is much better > > implement them in python-space, if you really use them a lot. (for > > example, if you have two columns with the same name, psycopg will > > happily overwrite the first one with the second.) >=20 > Probably best to raise >=20 > ProgrammingError("don't use SELECT * damnit, and go look about\ > AS in your SQL book") MySQLdb does this with a separate cursor class (DictCursor), and when it finds a conflicting name, it prepends the table name to the key, i.e. table.column. Of course, I agree completely with the comment about SELECT *... --=20 Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all that I yam." -- Popeye From morengo@nyc.rr.com Fri Jun 7 03:05:17 2002 From: morengo@nyc.rr.com (Michel Orengo) Date: Thu, 6 Jun 2002 22:05:17 -0400 Subject: [DB-SIG] MSAccess In-Reply-To: <20020606163511.GA3187@lilith.my-fqdn.de> Message-ID: """ if you found it useful. Looks like it never got finished. """ No it never got finished because I had to switch to more important (and lucrative ;-) things Using ADO with the *excellent* COM interface from Mark Hammond is a piece= of cake. The issue is MS documentation. I have started this project by encapsulating (an attempt to simplify) some ADO objects. Mark H. correctly so demonstrated the limits of my approach, and suggeste= d I'd rather spend my time building a compatible DB-API for ADO. That was my first and final trial. Looking back on this, I am not sure there is a lot of value in having a DB-API on top of ADO: the DB-API is somewhat too "low-level" for ADO. I consider DB-API being a more abstract ODBC. ADO sits on top of ODBC (and other drivers too.) If a common Python API existed for OO-access-to-DB, then implementation o= f this API using ADO would make sense. Regards, Michel -----Original Message----- From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf Of Gerhard H=E4ring Sent: Thursday, June 06, 2002 12:35 PM To: db-sig@python.org Subject: Re: [DB-SIG] MSAccess * William Dode [2002-06-06 16:26 +0200]: > I found a page about ADO http://www.e-coli.net/pyado.html, it seems > to work well also... i think it could be easy to make a DB2api > around it isnt'it ? Relatively easy, but it's some work to make it DB-API compliant. We're currently experiencing that in the PySQLite project: it's relatively easy to get something out the door, but a lot more work lies in the refinements. Btw. I've saved the following email that I could send you: From: Michel Orengo To: python-list@python.org Subject: [ANN]pre-release DBAPI2.0 for ADO Date: Wed, 5 Jul 2000 13:26:41 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) if you found it useful. Looks like it never got finished. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C93= 0 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C93= 0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From wilk@flibuste.net Fri Jun 7 09:17:45 2002 From: wilk@flibuste.net (William Dode) Date: Fri, 7 Jun 2002 10:17:45 +0200 Subject: [DB-SIG] MSAccess In-Reply-To: References: <20020606163511.GA3187@lilith.my-fqdn.de> Message-ID: <20020607101745.36717105.wilk@flibuste.net> hi, Even if it's not interesting to make a DB-API on top of ADO, i could use ADO alone. But i try it and found that it's very very slow when i compare to odbc of winext or mxodbc... Any idea ? For mxodbc, there is a problem with the licence not compatible with GNU/GPL. Even not open source, it break all the strategie of using other open source products. bye Le Thu, 6 Jun 2002 22:05:17 -0400 "Michel Orengo" écrivait: > """ > if you found it useful. Looks like it never got finished. > """ > No it never got finished because I had to switch to more important (and > lucrative ;-) things > > Using ADO with the *excellent* COM interface from Mark Hammond is a > piece of cake. The issue is MS documentation. I have started this > project by encapsulating (an attempt to simplify) some ADO objects. > Mark H. correctly so demonstrated the limits of my approach, and > suggested I'd rather spend my time building a compatible DB-API for ADO. > That was my first and final trial. > > Looking back on this, I am not sure there is a lot of value in having a > DB-API on top of ADO: the DB-API is somewhat too "low-level" for ADO. I > consider DB-API being a more abstract ODBC. ADO sits on top of ODBC (and > other drivers too.) > > If a common Python API existed for OO-access-to-DB, then implementation > of this API using ADO would make sense. > > Regards, > > Michel > > > -----Original Message----- > From: db-sig-admin@python.org [mailto:db-sig-admin@python.org]On Behalf > Of Gerhard Häring > Sent: Thursday, June 06, 2002 12:35 PM > To: db-sig@python.org > Subject: Re: [DB-SIG] MSAccess > > > * William Dode [2002-06-06 16:26 +0200]: > > I found a page about ADO http://www.e-coli.net/pyado.html, it seems > > to work well also... i think it could be easy to make a DB2api > > around it isnt'it ? > > Relatively easy, but it's some work to make it DB-API compliant. We're > currently experiencing that in the PySQLite project: it's relatively > easy to get something out the door, but a lot more work lies in the > refinements. > > Btw. I've saved the following email that I could send you: > > From: Michel Orengo > To: python-list@python.org > Subject: [ANN]pre-release DBAPI2.0 for ADO > Date: Wed, 5 Jul 2000 13:26:41 -0500 > X-Mailer: Internet Mail Service (5.5.2653.19) > > if you found it useful. Looks like it never got finished. > > Gerhard > -- > mail: gerhard bigfoot de registered Linux user #64239 > web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id > AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B > 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda > x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- William Dodé - Informaticien Indépendant http://www.flibuste.net From r.taylor@eris.qinetiq.com Fri Jun 7 11:34:24 2002 From: r.taylor@eris.qinetiq.com (Richard Taylor) Date: Fri, 7 Jun 2002 11:34:24 +0100 Subject: [DB-SIG] There is a better way Message-ID: <200206071134.26951.r.taylor@eris.qinetiq.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Following the previous helpful discussions about how best to work out what the returns from a query are without relying on DB specific exception values, I have a better attempt at how to do it. It would appear that using a combination of checking cursor.description and cursor.rowcount I can get the result that I need. The following code is what I have come up with: def query(cnx,q): """Simple wrapper function for DB API query. This will always return a list. The list will be empty for queries that do not contain a select, queries that return an empty result set and queries that result in errors. Errors will be reported on stderr. The parameters are: cnx - an open DB API v2.0 connection object q - an sql query string. """ try: cr = cnx.cursor() cr.execute (q) cnx.commit() except: type, value = sys.exc_info()[:2] sys.stderr.write("DB API execute failed with Exeception: %s, %s"\ % (type,value)) return [] # Trap selects that return nothing and # queries that do not contain a select. if cr.description == None or cr.rowcount == 0 : return [] try: res = cr.fetchall() except: type, value = sys.exc_info()[:2] sys.stderr.write("DB API fetch failed with Exeception: %s, %s"\ % (type,value)) return [] return res The intention is to provide a simple function for making queries on any DB API module that is guaranteed to return a list (possibility empty). Any errors are reported on stderr but they could be properagated. I would welcome comments on whether this will work on all DB API modules. I used the following simple test code to check that psycopg produced the behavior that was expected (output below the code). It would be interesting to see if other adaptors produce the same behavior. cnx = psycopg.connect("user=rtaylor dbname=rtaylor") cr = cnx.cursor() query(cnx,'drop table telephone') query(cnx,'create table telephone ("name" text, "tel" text)') query(cnx,"insert into telephone values ('Richard', '12345678')") query(cnx,"insert into telephone values ('Steve', '01002030')") cnx.commit() del cr # select of zero rows def check(q): ex_type = 'Not Set' ex_value = 'Not Set' rows = 'Not Set' cr = cnx.cursor() cr.execute(q) cnx.commit() desc = repr(cr.description) rowcount = repr(cr.rowcount) try: rows = cr.fetchall() ex_thrown = 0 except: ex_type, ex_value = sys.exc_info()[:2] ex_thrown = 1 return (str(rowcount),str(rows),str(ex_thrown), str(ex_type),str(ex_value),str(desc)) tests = {'Empty result': "select name from telephone where name = 'unknown'", 'Insert': "insert into telephone values('test','0000')", 'Update': "update telephone set name = 'new' where name = 'Richard'"} format = "%-12s %-8s %-8s %-9s %-20s %-20s %-30s" print format % ("test" , "rowcount", "rows", "ex_thrown", "ex_type", "ex_value", "description") print "=" * 100 for test in tests.keys(): t = (test,) + check(tests[test]) s = format % t print s Output from psyopg (probably horribly line wrapped): test rowcount rows ex_thrown ex_type ex_value description ==================================================================================================== Update 1 Not Set 1 psycopg.Error no results to fetch None Empty result 0 [] 0 Not Set Not Set (('name', 25, None, -1, None, None, None),) Insert 1 Not Set 1 psycopg.Error no results to fetch None Many thanks for everyones help in getting this right. I am much happier not relying on DB specific exception values. Richard - -- QinetiQ B105 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9AIww7Z7YaKfan9kRAgpyAKDhJZycIHl1TJyniFS8RRxiS0HrGgCgjcv9 LNPzDNCjxQ95x4uUXxbld6Q= =RX7q -----END PGP SIGNATURE----- From jacobs@penguin.theopalgroup.com Fri Jun 7 12:42:35 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Fri, 7 Jun 2002 07:42:35 -0400 (EDT) Subject: [DB-SIG] [ANN] pyPgSQL 2.1 released In-Reply-To: <1023379685.4424.2.camel@jwilhelm.ofsloans.com> Message-ID: On 6 Jun 2002, Joseph Wilhelm wrote: > On Thu, 2002-06-06 at 06:30, Andy Dustman wrote: > > > I'm curious... There are at least two actively maintained PostgreSQL > > interfaces (three if you count the one that comes with PostgreSQL). I've > > personally used psycopg a bit lately. What are the advantages and > > disadvantages of the various interfaces? > > > Another bit of curiosity... do either of these interfaces support > dictionary results? I'm currently using the 'pg' module provided with > the PostgreSQL distribution primarily for the fact that I have need of > dictionary results, and pg gladly supplies them. However, if one of > these is "better", and provides me with dicts, I would love to give it a > shot. If you are using Python 2.2, I have a new open souce module you may want to try out. It uses some of the new Python 2.2 features to produce light-weight objects that have most of the functionality of tuples _and_ dictionaries, but are less expensive than dictionaries. i.e., you can do the following: row[0] # access by index row[3:7] # access by slice row['Foo'] # access by item interface row.Foo # access by attribute interface Field names accessors can also be made case-insensitive. Here are a few benchmarks that measure the time and memory required to create 200,000 result objects of various types with 11 integer values: Time Approx. SIZE (sec) Bytes/row -------- ------ --------- baseline: 4,744KB 0.56 - tuple: 18,948KB 2.49 73 dict: 117MB 13.50 589 Pure Python db_row: 18,960KB 17.23 73 C db_row: 18,924KB 4.85 73 For more information take a look at http://opensource.theopalgroup.com -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From jacobs@penguin.theopalgroup.com Fri Jun 7 12:47:45 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Fri, 7 Jun 2002 07:47:45 -0400 (EDT) Subject: [DB-SIG] [ANNOUNCE] DB-API 2.0 module for Microsoft ADO Message-ID: Since there seems to be some interest, I have released our toy DB-API 2.0 driver for Microsoft ADO. It is mostly functional, though only lightly tested. The only major thing missing is the ability to bind parameters, which should not be too hard to add -- most of the code is already there. Yes, I know it is slow, though that has more to do with ADO than our driver. Anyhow, give it a try. Let me know what you think. Patches that fix bugs or add features will be greatfully accepted. Grab it from: http://opensource.theopalgroup.com Regards, -Kevin Jacobs -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From c.attianese@cib.na.cnr.it Fri Jun 7 14:40:58 2002 From: c.attianese@cib.na.cnr.it (Carla Attianese) Date: Fri, 7 Jun 2002 15:40:58 +0200 Subject: [DB-SIG] informixdb Message-ID: <009501c20e28$f4dd26d0$dc05a48c@epicuro> This is a multi-part message in MIME format. ------=_NextPart_000_0092_01C20E39.B811E360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody, I'm actually working with informixdb modulke and I have some questions = about it. First of all, can you give me an example of the right syntax to start a = conenction and to run the execute method? Finally, Do I have to call the execute method associated with the cursor = object or with the conenction object? I hope you can help me best regards carla Carla Attianese c.attianese@cib.na.cnr.it CNR - Cybernetics Institute Via Campi Flegrei, 34 I-80072 Pozzuoli (Naples), Italy +39818675157 ------=_NextPart_000_0092_01C20E39.B811E360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everybody,
I'm actually working with informixdb = modulke and I=20 have some questions about it.
First of all, can you give me an = example of the=20 right syntax to start a conenction and to run the execute = method?
Finally, Do I have to call the execute = method=20 associated with the cursor object or with the conenction = object?
I hope you can help me
best regards
carla
 
Carla Attianese
c.attianese@cib.na.cnr.itCNR -=20 Cybernetics Institute
Via Campi Flegrei, 34  I-80072
Pozzuoli = (Naples), Italy
+39818675157
------=_NextPart_000_0092_01C20E39.B811E360-- From wilk@flibuste.net Fri Jun 7 17:15:05 2002 From: wilk@flibuste.net (William Dode) Date: Fri, 7 Jun 2002 18:15:05 +0200 Subject: [DB-SIG] [ANNOUNCE] DB-API 2.0 module for Microsoft ADO In-Reply-To: References: Message-ID: <20020607181505.3a45c88b.wilk@flibuste.net> Le Fri, 7 Jun 2002 07:47:45 -0400 (EDT) Kevin Jacobs écrivait: > Since there seems to be some interest, I have released our toy DB-API > 2.0 driver for Microsoft ADO. It is mostly functional, though only > lightly tested. The only major thing missing is the ability to bind > parameters, which should not be too hard to add -- most of the code is > already there. Yes, I know it is slow, though that has more to do with > ADO than our driver. fine ! you find a way that is not so slow (i was using movenext and not getrows...) i had to make some little corrections to make works with odbc, i'll send you somes patchs next time i'll reboot on windows... thanks > > Anyhow, give it a try. Let me know what you think. Patches that fix > bugs or add features will be greatfully accepted. > > Grab it from: > http://opensource.theopalgroup.com > > Regards, > -Kevin Jacobs > > -- > Kevin Jacobs > The OPAL Group - Enterprise Systems Architect > Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com > Fax: (216) 986-0714 WWW: http://www.theopalgroup.com > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- William Dodé - Informaticien Indépendant http://www.flibuste.net From wtrenker@shaw.ca Fri Jun 7 19:53:48 2002 From: wtrenker@shaw.ca (William Trenker) Date: Fri, 07 Jun 2002 11:53:48 -0700 Subject: [DB-SIG] Standard values for type_code? Message-ID: <5.1.1.2.0.20020607112557.02d1b5b0@shawmail> --Boundary_(ID_9BJYmcNUOlSv1+qMAMJpQQ) Content-type: text/plain; x-avg-checked=avg-ok-3B581A7F; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT The DB-API 2.0 spec requires that the tuple returned for each column by cursor.description has a type_code as the 2nd item in the tuple. The spec states that "the type_code can be interpreted by comparing it to the Type Objects" which are described in the section "Type Objects and Constructors". Is there a list of standard values for type_code? Thanks Bill http://pysqlite.sourceforge.net ---------- "The commandments of the LORD are right, bringing joy to the heart. The commands of the LORD are clear, giving insight to life . . . For this is the love of God, that we keep His commandments. And His commandments are not burdensome." (Psalm 19:8, 1John 5:3) torahteacher.com --Boundary_(ID_9BJYmcNUOlSv1+qMAMJpQQ) Content-type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-3B581A7F Content-transfer-encoding: 7BIT Content-disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.363 / Virus Database: 201 - Release Date: 5/21/02 --Boundary_(ID_9BJYmcNUOlSv1+qMAMJpQQ)-- From juenglin@informatik.uni-freiburg.de Tue Jun 11 12:05:04 2002 From: juenglin@informatik.uni-freiburg.de (Ralf Juengling) Date: 11 Jun 2002 13:05:04 +0200 Subject: [DB-SIG] Help on MySQL exception Message-ID: <1023793504.768.91.camel@leto> Hi, I'm a dbms novice and recently wrote a small python program which feeds data into a mySQL server. Now this program is occasionally stopped by an mysql exception for no apparent reason: "mySQL server has gone away" (see below). I've no idea what's going wrong, since there is another python program continuously communicating with mysql, which is not affected... Any hint is very appreciated, thanks, Ralf <-- snip --> cursor.execute(queryStr) File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 61, in execute r =3D self._query(query) File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 168, in _query rowcount =3D self._BaseCursor__do_query(q) File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 112, in __do_query db.query(q) _mysql_exceptions.OperationalError: (2006, 'MySQL server has gone away') --=20 -------------------------------------------------------------------------- Ralf J=FCngling Institut f=FCr Informatik - Lehrstuhl f=FCr Mustererkennung & Bildverarbeitung Georges-K=F6hler-Allee =20 Geb=E4ude 52 Tel: +49-(0)761-203-8215 79110 Freiburg Fax: +49-(0)761-203-8262 -------------------------------------------------------------------------- From hancock@anansispaceworks.com Tue Jun 11 07:40:29 2002 From: hancock@anansispaceworks.com (Terry Hancock) Date: Mon, 10 Jun 2002 23:40:29 -0700 Subject: [DB-SIG] MySQLdb warnings problem Message-ID: <3D059B5D.61EF9DB8@anansispaceworks.com> Hi all, I'm in the middle of writing a Zope/MySQL project, and I use a Python/MySQL crawler to do some database maintenance tasks. I'm writing this crawler now, and it's my first experience with "Python Database API 2.0". I originally posted this question on the main python list, not knowing where to ask, but I was refered here, so I hope someone can give me a clue as to what's going on with this: The program is fairly long, but what happens is that it scans the database for entries in a database table called "user" and calculates some statistics for them based on other tables. All the retrievals work fine, but I get a funny traceback when I write the data back into the user's row in the table: Traceback (most recent call last): File "Styx.py", line 258, in ? styx.crawl( styx.params['P_Styx'], styx_tasks) File "Crawler.py", line 193, in crawl task[1](argval) # Operate on it File "Styx.py", line 165, in compute_user_stats dbcursor.execute(sqlcmd) File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 61, in execute r = self._query(query) File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 168, in _query rowcount = self._BaseCursor__do_query(q) File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 118, in __do_query self._check_for_warnings() File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 150, in _check_for_warnings raise Warning, self._info _mysql_exceptions.Warning: Rows matched: 1 Changed: 0 Warnings: 1 For reference, here's a snippet of the code where this broke: sqlcmd= """ UPDATE user SET nposts=%d, nrecent=%d, keytopic='%s' WHERE username='%s' """ % ( n_posts, n_recent, keytopic, user[0] ) #print sqlcmd #try: dbcursor.execute(sqlcmd) #except: # pass [It's already been pointed out to me that dbcursor.execute provides a safer quoting mechanism than I'm using here -- but as the output below shows, that's definitely not the problem here.] As the commented-out lines indicate, I tried ignoring this problem. Doing so seems to make the program work fine, but I can't figure out why it should be an issue in the first place (and I generally prefer not to just ignore warnings, especially without understanding them). The thing is, what's the warning message? Nothing was changed this time, because a previous run already updated the stats (the first run said "Rows matched: 1 Changed: 1 Warnings: 1"). Uncommenting the print statement shows what the actual SQL was: UPDATE user SET nposts=7, nrecent=0, keytopic='/' WHERE username='anonymous' which looks legit to me, though I'm not really an SQL expert. So maybe it's raising a warning every time I write to the database? Why? And more to the point, what is the warning -- shouldn't it be giving me some kind of message from MySQL? Should I just stick the try-except code back in and forget about it, or am I missing a step somewhere? Any ideas would be much appreciated. Thanks! Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com ------------------------------------------------------ From hancock@anansispaceworks.com Tue Jun 11 07:40:44 2002 From: hancock@anansispaceworks.com (Terry Hancock) Date: Mon, 10 Jun 2002 23:40:44 -0700 Subject: [DB-SIG] MySQLdb warnings problem Message-ID: <3D059B6C.193F71D0@anansispaceworks.com> Hi all, I'm in the middle of writing a Zope/MySQL project, and I use a Python/MySQL crawler to do some database maintenance tasks. I'm writing this crawler now, and it's my first experience with "Python Database API 2.0". I originally posted this question on the main python list, not knowing where to ask, but I was refered here, so I hope someone can give me a clue as to what's going on with this: The program is fairly long, but what happens is that it scans the database for entries in a database table called "user" and calculates some statistics for them based on other tables. All the retrievals work fine, but I get a funny traceback when I write the data back into the user's row in the table: Traceback (most recent call last): File "Styx.py", line 258, in ? styx.crawl( styx.params['P_Styx'], styx_tasks) File "Crawler.py", line 193, in crawl task[1](argval) # Operate on it File "Styx.py", line 165, in compute_user_stats dbcursor.execute(sqlcmd) File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 61, in execute r = self._query(query) File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 168, in _query rowcount = self._BaseCursor__do_query(q) File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 118, in __do_query self._check_for_warnings() File "/usr/local/narya/lib/python2.1/site-packages/MySQLdb/cursors.py", line 150, in _check_for_warnings raise Warning, self._info _mysql_exceptions.Warning: Rows matched: 1 Changed: 0 Warnings: 1 For reference, here's a snippet of the code where this broke: sqlcmd= """ UPDATE user SET nposts=%d, nrecent=%d, keytopic='%s' WHERE username='%s' """ % ( n_posts, n_recent, keytopic, user[0] ) #print sqlcmd #try: dbcursor.execute(sqlcmd) #except: # pass [It's already been pointed out to me that dbcursor.execute provides a safer quoting mechanism than I'm using here -- but as the output below shows, that's definitely not the problem here.] As the commented-out lines indicate, I tried ignoring this problem. Doing so seems to make the program work fine, but I can't figure out why it should be an issue in the first place (and I generally prefer not to just ignore warnings, especially without understanding them). The thing is, what's the warning message? Nothing was changed this time, because a previous run already updated the stats (the first run said "Rows matched: 1 Changed: 1 Warnings: 1"). Uncommenting the print statement shows what the actual SQL was: UPDATE user SET nposts=7, nrecent=0, keytopic='/' WHERE username='anonymous' which looks legit to me, though I'm not really an SQL expert. So maybe it's raising a warning every time I write to the database? Why? And more to the point, what is the warning -- shouldn't it be giving me some kind of message from MySQL? Should I just stick the try-except code back in and forget about it, or am I missing a step somewhere? Any ideas would be much appreciated. Thanks! Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com ------------------------------------------------------ From andy@dustman.net Tue Jun 11 20:32:18 2002 From: andy@dustman.net (Andy Dustman) Date: 11 Jun 2002 15:32:18 -0400 Subject: [DB-SIG] Help on MySQL exception In-Reply-To: <1023793504.768.91.camel@leto> References: <1023793504.768.91.camel@leto> Message-ID: <1023823938.21859.11.camel@4.0.0.10.in-addr.arpa> On Tue, 2002-06-11 at 07:05, Ralf Juengling wrote: > I'm a dbms novice and recently wrote a small python program which feeds > data into a mySQL server. Now this program is occasionally stopped by > an mysql exception for no apparent reason: "mySQL server has gone away" > (see below). You'll probably have to look at the MySQL server logs to find out what went wrong. What versions of MySQL (client libraries and server) are you using, and what version of MySQLdb? >>> import MySQLdb >>> db=MySQLdb.connect(...) >>> MySQLdb.version_info (0, 9, 2, 'gamma', 1) >>> MySQLdb._mysql.get_client_info() '3.23.49' >>> db.get_server_info() '3.23.49-Max' >>> -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From andy@dustman.net Tue Jun 11 20:38:24 2002 From: andy@dustman.net (Andy Dustman) Date: 11 Jun 2002 15:38:24 -0400 Subject: [DB-SIG] MySQLdb warnings problem In-Reply-To: <3D059B6C.193F71D0@anansispaceworks.com> References: <3D059B6C.193F71D0@anansispaceworks.com> Message-ID: <1023824304.21716.17.camel@4.0.0.10.in-addr.arpa> On Tue, 2002-06-11 at 02:40, Terry Hancock wrote: > So maybe it's raising a warning every time I write to the > database? Why? And more to the point, what is the warning -- > shouldn't it be giving me some kind of message from MySQL? It's impossible to say what the warning is without knowing anything about your database schema. Likely you are trying to set a value that isn't allowed by the schema: Notice that you did not actually change any rows: _mysql_exceptions.Warning: Rows matched: 1 Changed: 0 Warnings: 1 MySQL itself does not give any more information than this, unfortunately. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From zen@shangri-la.dropbear.id.au Wed Jun 12 07:22:03 2002 From: zen@shangri-la.dropbear.id.au (Stuart Bishop) Date: Wed, 12 Jun 2002 16:22:03 +1000 Subject: [DB-SIG] There is a better way In-Reply-To: <200206071134.26951.r.taylor@eris.qinetiq.com> Message-ID: On Friday, June 7, 2002, at 08:34 PM, Richard Taylor wrote: > if cr.description == None or cr.rowcount == 0 : > return [] > > try: > res = cr.fetchall() > I would welcome comments on whether this will work on all DB API > modules. Unfortunatly, rowcount may be undefined until all results have been retrieved (otherwise the DB may have to execute some massive query twice - once to determine the rowcount and once to actually retrieve the rows - in cases where the result cannot be cached in memory). -- Stuart Bishop http://shangri-la.dropbear.id.au/ From r.taylor@eris.qinetiq.com Wed Jun 12 08:01:28 2002 From: r.taylor@eris.qinetiq.com (Richard Taylor) Date: Wed, 12 Jun 2002 08:01:28 +0100 Subject: [DB-SIG] There is a better way In-Reply-To: References: Message-ID: <200206120801.30251.r.taylor@eris.qinetiq.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 June 2002 7:22 am, Stuart Bishop wrote: > On Friday, June 7, 2002, at 08:34 PM, Richard Taylor wrote: > > if cr.description == None or cr.rowcount == 0 : > > return [] > > > > try: > > res = cr.fetchall() > > > > > > I would welcome comments on whether this will work on all DB API > > modules. > > Unfortunatly, rowcount may be undefined until all results have been > retrieved (otherwise the DB may have to execute some massive query > twice - > once to determine the rowcount and once to actually retrieve the rows - > in cases where the result cannot be cached in memory). I am not sure that it matters. It would only matter if the rowcount was set to zero when there really was some rows returned. That would appear to me to be unlikely. If it is possible that cr.rowcount is not defined at all then I guess the conditional could be: if cr.description == None or (hasattr(cr,'rowcount') and cr.rowcount == 0): return [] This would assume that if a table description is set and rowcount is not yet defined some rows have been returned from the database. Or at least that a call to fetchXXX will not raise an exception. Any of the db module maintainers want to comment on this? I believe that psycopg would obey this condition because rowcount appears to be set to zero when zero rows are returned. Richard - -- QinetiQ B105 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9BvHI7Z7YaKfan9kRAqRRAJ49mBIZRKl4FcLYtPMvVlAOB1+qvACgyEnU vLBUT0+hyOQrxqyvxGyjsSA= =mfvM -----END PGP SIGNATURE----- From mal@lemburg.com Wed Jun 12 09:29:43 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jun 2002 10:29:43 +0200 Subject: [DB-SIG] There is a better way References: <200206120801.30251.r.taylor@eris.qinetiq.com> Message-ID: <3D070677.7080908@lemburg.com> Richard Taylor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 12 June 2002 7:22 am, Stuart Bishop wrote: > >>On Friday, June 7, 2002, at 08:34 PM, Richard Taylor wrote: >> >>> if cr.description == None or cr.rowcount == 0 : >>> return [] >>> >>> try: >>> res = cr.fetchall() >>> >>> >>>I would welcome comments on whether this will work on all DB API >>>modules. >> >>Unfortunatly, rowcount may be undefined until all results have been >>retrieved (otherwise the DB may have to execute some massive query >>twice - >>once to determine the rowcount and once to actually retrieve the rows - >>in cases where the result cannot be cached in memory). > > > I am not sure that it matters. It would only matter if the rowcount was set to > zero when there really was some rows returned. That would appear to me to be > unlikely. If it is possible that cr.rowcount is not defined at all then I > guess the conditional could be: > > if cr.description == None or (hasattr(cr,'rowcount') and cr.rowcount == 0): > return [] > > This would assume that if a table description is set and rowcount is not yet > defined some rows have been returned from the database. Or at least that a > call to fetchXXX will not raise an exception. > > Any of the db module maintainers want to comment on this? I believe that > psycopg would obey this condition because rowcount appears to be set to zero > when zero rows are returned. The .rowcount variable must be set to -1 if it is unknown for some reason, e.g. if no query has been executed on the cursor of the database does not have the information available. A .rowcount of 0 always indicates that the result set is empty. Unfortunately, some database drivers and interfaces are broken in this respect (including some ODBC drivers out there), so applications should be aware of this. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From r.taylor@eris.qinetiq.com Wed Jun 12 10:03:41 2002 From: r.taylor@eris.qinetiq.com (Richard Taylor) Date: Wed, 12 Jun 2002 10:03:41 +0100 Subject: [DB-SIG] There is a better way In-Reply-To: <3D070677.7080908@lemburg.com> References: <200206120801.30251.r.taylor@eris.qinetiq.com> <3D070677.7080908@lemburg.com> Message-ID: <200206121003.43069.r.taylor@eris.qinetiq.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 June 2002 9:29 am, M.-A. Lemburg wrote: > Richard Taylor wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Wednesday 12 June 2002 7:22 am, Stuart Bishop wrote: > >>On Friday, June 7, 2002, at 08:34 PM, Richard Taylor wrote: > >>> if cr.description == None or cr.rowcount == 0 : > >>> return [] > >>> > >>> try: > >>> res = cr.fetchall() > >>> > >>> > >>>I would welcome comments on whether this will work on all DB API > >>>modules. > [snip] > The .rowcount variable must be set to -1 if it is unknown for > some reason, e.g. if no query has been executed on the cursor > of the database does not have the information available. > > A .rowcount of 0 always indicates that the result set is > empty. Unfortunately, some database drivers and interfaces > are broken in this respect (including some ODBC drivers > out there), so applications should be aware of this. So that means that the original code should work if the driver is not broken? i.e. if cr.description == None or cr.rowcount == 0 : return [] Richard - -- QinetiQ B105 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9Bw5t7Z7YaKfan9kRAlL/AJkBtTdm/o76sEuwJNZTHKqdn0gmzACffDQx C3BXbmeKaKIPJjonI80+C5s= =XGzq -----END PGP SIGNATURE----- From mal@lemburg.com Wed Jun 12 10:22:23 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 12 Jun 2002 11:22:23 +0200 Subject: [DB-SIG] There is a better way References: <200206120801.30251.r.taylor@eris.qinetiq.com> <3D070677.7080908@lemburg.com> <200206121003.43069.r.taylor@eris.qinetiq.com> Message-ID: <3D0712CF.9080301@lemburg.com> Richard Taylor wrote: >>A .rowcount of 0 always indicates that the result set is >>empty. Unfortunately, some database drivers and interfaces >>are broken in this respect (including some ODBC drivers >>out there), so applications should be aware of this. > > > So that means that the original code should work if the driver is not broken? > > i.e. > > if cr.description == None or cr.rowcount == 0 : > return [] Don't know why you test .description here. cr.rowcount should suffice. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From r.taylor@eris.qinetiq.com Wed Jun 12 10:34:36 2002 From: r.taylor@eris.qinetiq.com (Richard Taylor) Date: Wed, 12 Jun 2002 10:34:36 +0100 Subject: [DB-SIG] There is a better way In-Reply-To: <3D0712CF.9080301@lemburg.com> References: <200206121003.43069.r.taylor@eris.qinetiq.com> <3D0712CF.9080301@lemburg.com> Message-ID: <200206121034.38268.r.taylor@eris.qinetiq.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 June 2002 10:22 am, M.-A. Lemburg wrote: > Richard Taylor wrote: >> [snip] > > > > i.e. > > > > if cr.description == None or cr.rowcount == 0 : > > return [] > > Don't know why you test .description here. cr.rowcount should suffice. The reason for checking .description is that I want to be sure that an exception raised from fetchXXX is because an error has occurred rather than no rows to return. And I want this to be the case regardless of the type of query that has been passed to execute(). The check of .description (I think) is the only way to be sure that a 'select' type query has been passed to execute(). The background to this is in the "[DB-SIG] Is there a better way of doing this?" thread from last week. Richard - -- QinetiQ B105 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9BxWs7Z7YaKfan9kRAnazAJ9ge9OB2W5VvBWAaDSNtBitkQX0CQCeM2nE 2PC4NvvwpZBw1S72N42ETlA= =9h7T -----END PGP SIGNATURE----- From TKeating@origin.ea.com Wed Jun 12 16:44:10 2002 From: TKeating@origin.ea.com (Keating, Tim) Date: Wed, 12 Jun 2002 10:44:10 -0500 Subject: [DB-SIG] There is a better way Message-ID: <9B8090A2F0EBDB4ABD59B08E81C1A6842F5F77@osi-postal.osi.ad.ea.com> And on Oracle, cr.description is not defined for ref cursors. > -----Original Message----- > From: Stuart Bishop [mailto:zen@shangri-la.dropbear.id.au] > Sent: Wednesday, June 12, 2002 1:22 AM > To: r.taylor@eris.qinetiq.com > Cc: db-sig@python.org > Subject: Re: [DB-SIG] There is a better way > > > > On Friday, June 7, 2002, at 08:34 PM, Richard Taylor wrote: > > > if cr.description == None or cr.rowcount == 0 : > > return [] > > > > try: > > res = cr.fetchall() > > > > I would welcome comments on whether this will work on all DB API > > modules. > > Unfortunatly, rowcount may be undefined until all results have been > retrieved (otherwise the DB may have to execute some massive query > twice - > once to determine the rowcount and once to actually retrieve > the rows - > in cases where the result cannot be cached in memory). > > -- > Stuart Bishop > http://shangri-la.dropbear.id.au/ > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From matt@zope.com Wed Jun 12 19:46:22 2002 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 12 Jun 2002 14:46:22 -0400 Subject: [DB-SIG] There is a better way References: <9B8090A2F0EBDB4ABD59B08E81C1A6842F5F77@osi-postal.osi.ad.ea.com> Message-ID: <3D0796FE.3040209@zope.com> Keating, Tim wrote: >And on Oracle, cr.description is not defined for ref cursors. > > > Actually, for DCOracle2, thats just a bug in the python layer -- you can call cr.describe() to ASK for the description; its just that the python layer doesn't do that automatically (because its normally done on an execute). I just fixed that in CVS. -- Matt Kromer Zope Corporation http://www.zope.com/ From ramrom@earthling.net Sun Jun 16 00:40:22 2002 From: ramrom@earthling.net (Bob Gailer) Date: Sat, 15 Jun 2002 17:40:22 -0600 Subject: [DB-SIG] Oracle ODBC Message-ID: <5.1.0.14.0.20020615173917.028505d8@pop.viawest.net> I'm running IDLE on Windows NT4, connecting to Oracle 8i (running on UNIX) using Oracle's ODBC driver. After a few successful ODBC cursor executes, pythonw.exe crashes, raising a Dr Watson error. I had first tried this using PythonWin, and it just abruptly terminates with no error messages. Do you have any experience with Oracle ODBC in general, or with this problem in particular. Bob Gailer mailto:ramrom@earthling.net 303 442 2625 From ramrom@earthling.net Sun Jun 16 02:43:01 2002 From: ramrom@earthling.net (Bob Gailer) Date: Sat, 15 Jun 2002 19:43:01 -0600 Subject: [DB-SIG] Oracle ODBC In-Reply-To: <5.1.0.14.0.20020615170052.02858b68@pop.viawest.net> References: Message-ID: <5.1.0.14.0.20020615194146.02884a90@pop.viawest.net> --=====================_44112670==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I am programming in Python (via IDLE and PythonWin) on a Win NT4 box, accessing Oracle 8i database on Solaris 2.8 via Oracle's ODBC driver. I am having good success running pl/sql through this interface; what I'd like to do is to get a value back from the pl/sql into Python. Any ideas? Bob Gailer mailto:ramrom@earthling.net 303 442 2625 --=====================_44112670==_.ALT Content-Type: text/html; charset="us-ascii" I am programming in Python (via IDLE and PythonWin) on a Win NT4 box, accessing Oracle 8i database on Solaris 2.8 via Oracle's ODBC driver.

I am having good success running pl/sql through this interface; what I'd like to do is to get a value back from the pl/sql into Python. Any ideas?

Bob Gailer
mailto:ramrom@earthling.net
303 442 2625
--=====================_44112670==_.ALT-- From ramrom@earthling.net Sun Jun 16 03:19:49 2002 From: ramrom@earthling.net (Bob Gailer) Date: Sat, 15 Jun 2002 20:19:49 -0600 Subject: [DB-SIG] Re: Oracle ODBC (crashing) Message-ID: <5.1.0.14.0.20020615201845.02858b68@pop.viawest.net> --=====================_46320385==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed More info regarding the crashes: 1) things seem to go OK when running from the Python command window. 2) IDLE crashes with access violation 0xC000005. 3) PythonWin just terminates. Bob Gailer mailto:ramrom@earthling.net 303 442 2625 --=====================_46320385==_.ALT Content-Type: text/html; charset="us-ascii" More info regarding the crashes:
1) things seem to go OK when running from the Python command window.
2) IDLE crashes with access violation 0xC000005.
3) PythonWin just terminates.

Bob Gailer
mailto:ramrom@earthling.net
303 442 2625
--=====================_46320385==_.ALT-- From karl@putland.linux-site.net Sun Jun 16 03:21:32 2002 From: karl@putland.linux-site.net (Karl Putland) Date: 15 Jun 2002 20:21:32 -0600 Subject: [DB-SIG] Re: [FRPythoneers] Oracle ODBC In-Reply-To: <5.1.0.14.0.20020615194146.02884a90@pop.viawest.net> References: <5.1.0.14.0.20020615194146.02884a90@pop.viawest.net> Message-ID: <1024194092.2115.16.camel@mars.putland.int> On Sat, 2002-06-15 at 19:43, Bob Gailer wrote: > I am programming in Python (via IDLE and PythonWin) on a Win NT4 box, > accessing Oracle 8i database on Solaris 2.8 via Oracle's ODBC driver. > > I am having good success running pl/sql through this interface; what I'd > like to do is to get a value back from the pl/sql into Python. Any ideas? > Try using DCOracle2 from the zope site. It handles procedures and functinos very nicely. -- Karl Putland Director of Technical Operations ShipEze Inc From haering_postgresql@gmx.de Sun Jun 16 03:33:27 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Sun, 16 Jun 2002 04:33:27 +0200 Subject: [DB-SIG] Re: Oracle ODBC (crashing) In-Reply-To: <5.1.0.14.0.20020615201845.02858b68@pop.viawest.net> References: <5.1.0.14.0.20020615201845.02858b68@pop.viawest.net> Message-ID: <20020616023326.GA4185@lilith.my-fqdn.de> * Bob Gailer [2002-06-15 20:19 -0600]: > More info regarding the crashes: > 1) things seem to go OK when running from the Python command window. > 2) IDLE crashes with access violation 0xC000005. > 3) PythonWin just terminates. Which ODBC module are you using? The one installed by default with the win32 extensions (it's unsupported)? If yes, did you read http://www.python.org/windows/win32/odbc.html Stable solutions for accessing Oracle databases on Windows: - mxODBC - DCOracle2 - cx_Oracle - ADO/win32 extensions (not a DB-API module, though) Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From ramrom@earthling.net Sun Jun 16 04:06:39 2002 From: ramrom@earthling.net (Bob Gailer) Date: Sat, 15 Jun 2002 21:06:39 -0600 Subject: [DB-SIG] Re: Oracle ODBC (crashing) Message-ID: <5.1.0.14.0.20020615210621.028c0d70@pop.viawest.net> >Which ODBC module are you using? This is what I do, copied from http://www.python.org/windows/win32/odbc.html import dbi,odbc s=odbc.odbc("oracle/userid/password") Bob Gailer mailto:ramrom@earthling.net 303 442 2625 From rob@pangalactic.org Mon Jun 17 17:18:54 2002 From: rob@pangalactic.org (Rob Riggs) Date: Mon, 17 Jun 2002 10:18:54 -0600 Subject: [DB-SIG] Re: [FRPythoneers] Oracle ODBC References: <5.1.0.14.0.20020615194146.02884a90@pop.viawest.net> Message-ID: <3D0E0BEE.5080801@pangalactic.org> Bob Gailer wrote: > I am programming in Python (via IDLE and PythonWin) on a Win NT4 box, > accessing Oracle 8i database on Solaris 2.8 via Oracle's ODBC driver. > > I am having good success running pl/sql through this interface; what > I'd like to do is to get a value back from the pl/sql into Python. Any > ideas? > > Bob Gailer > mailto:ramrom@earthling.net > 303 442 2625 > I'm not sure how to do this via ODBC. (I've never done it.) However, you can do this with DCOracle2, a Python DB API 2.0 compliant database adapter from Digital Creations. You do this by either using cursor.callproc() or the cursor.procedure object. http://www.zope.org/Members/matt/dco2 -Rob From ade@pabrikweb.net Tue Jun 18 06:38:57 2002 From: ade@pabrikweb.net (fajar) Date: Tue, 18 Jun 2002 12:38:57 +0700 Subject: [DB-SIG] (no subject) Message-ID: <3D0EC771.7000909@pabrikweb.net> From ryanw@inktomi.com Wed Jun 19 22:18:14 2002 From: ryanw@inktomi.com (Ryan Weisenberger) Date: Wed, 19 Jun 2002 14:18:14 -0700 Subject: [DB-SIG] Quoting table and column names Message-ID: <4.3.2.7.2.20020619140133.00b5b408@inkt-3.inktomi.com> Is it safe to ALWAYS quote table names and column names in SQL statements? My python app queries against several different kinds of databases, most notably Oracle 8 and 9, MS SQL Server 2000, and Sybase. When table and column names contain spaces or characters (':' or '-'), I surround them with double quotes. So is it safe to always do this? I thought at one time I discovered that some dbs don't like this. Thanks, Ryan _________________________ Ryan Weisenberger Software Developer ryanw@inktomi.com (650) 653-4595 _________________________ From chris@cogdon.org Wed Jun 19 22:19:48 2002 From: chris@cogdon.org (Chris Cogdon) Date: Wed, 19 Jun 2002 14:19:48 -0700 Subject: [DB-SIG] Quoting table and column names In-Reply-To: <4.3.2.7.2.20020619140133.00b5b408@inkt-3.inktomi.com> References: <4.3.2.7.2.20020619140133.00b5b408@inkt-3.inktomi.com> Message-ID: <200206191419.48561.chris@cogdon.org> On Wednesday 19 June 2002 14:18, Ryan Weisenberger wrote: > Is it safe to ALWAYS quote table names and column names in SQL > statements? My python app queries against several different kinds of > databases, most notably Oracle 8 and 9, MS SQL Server 2000, and > Sybase. When table and column names contain spaces or characters (':' = or > '-'), I surround them with double quotes. So is it safe to always do > this? I thought at one time I discovered that some dbs don't like this= =2E This is DBSS specific. For example, Postgresql requires you to use single quotes when you want t= o=20 generate a string literal, and double quotes when you need to quote an en= tity=20 name (column, table, etc) that has spaces in it. However, MySQL decide to not follow SQL standards, and lets you use singl= e or=20 double quotes to specify string literals, and you need to use backticks t= o=20 quote an entity name (Can you see my anti-MySQL bias, here? :) So, if you're quite willing to reject MySQL as a valid target for your=20 application "because it doesn't follow standards", then the answer is yes= :) --=20 ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From magnus@thinkware.se Thu Jun 20 01:04:43 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Thu, 20 Jun 2002 02:04:43 +0200 Subject: [DB-SIG] Quoting table and column names In-Reply-To: <4.3.2.7.2.20020619140133.00b5b408@inkt-3.inktomi.com> Message-ID: <5.1.0.14.0.20020620015617.0239b5b8@www.thinkware.se> At 14:18 2002-06-19 -0700, Ryan Weisenberger wrote: >Is it safe to ALWAYS quote table names and column names in SQL=20 >statements? My python app queries against several different kinds of=20 >databases, most notably Oracle 8 and 9, MS SQL Server 2000, and=20 >Sybase. When table and column names contain spaces or characters (':' or= =20 >'-'), I surround them with double quotes. So is it safe to always do=20 >this? I thought at one time I discovered that some dbs don't like this. If my memory serves me right, at least some RDBMS consider case to be signicant in quoted strings. So select * from "mytable" and SELECT * FROM "MYTABLE" are different things, while select * from mytable and SELECT * FROM MYTABLE are the same. Also CREATE TABLE MYTABLE (...) is the same as create table mytable (...) but which quoted select will be right? Is the upper case or the lower case version "right"? "MYTABLE" or "mytable"? As far as I remember, this varies between vendors... --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From subscriptions@gnumed.net Thu Jun 20 12:49:12 2002 From: subscriptions@gnumed.net (Horst Herb) Date: Thu, 20 Jun 2002 21:49:12 +1000 Subject: [DB-SIG] Experiences with DB-API2.0 Message-ID: <200206202149.12282@gnumed.net> We wanted to make our project independend of database backends, or at least of database adapters as it is supposed to be truly multi platform and most adapters aren't. We thought DB-API was a great idea. That is, until we tried....: 1.) Connection strings incompatible between the 3 "most popular" Postgres adatpters - easy enough to fix, just a few "if....then..else" However, becomes tedious if you have hundreds of connections :-(( 2.) Returned date formats incompatible despite all of them using mxDateTime 3.) Frustrated, we gave up further tests for now. Are we doing something wrong or are the specifications that ambiguous that not even these simple issues can remain compatible? Am I rightfully disappointed or are changes already on the way? Horst From tjenkins@devis.com Thu Jun 20 12:54:55 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 20 Jun 2002 07:54:55 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <200206202149.12282@gnumed.net> References: <200206202149.12282@gnumed.net> Message-ID: <1024574095.583.113.camel@asimov> On Thu, 2002-06-20 at 07:49, Horst Herb wrote: > We wanted to make our project independend of database backends, or at least > of database adapters as it is supposed to be truly multi platform and most > adapters aren't. > > We thought DB-API was a great idea. That is, until we tried....: > > 1.) Connection strings incompatible between the 3 "most popular" Postgres > adatpters - easy enough to fix, just a few "if....then..else" > However, becomes tedious if you have hundreds of connections :-(( > > 2.) Returned date formats incompatible despite all of them using mxDateTime > > 3.) Frustrated, we gave up further tests for now. > > Are we doing something wrong or are the specifications that ambiguous that > not even these simple issues can remain compatible? > Am I rightfully disappointed or are changes already on the way? > Same thing here Horst. Also exception handling is difficult as each has their own exception types. This is one of the reasons why I'm now subscribed on this list. We're a big postgres & python company (with Access mixed in ). Having seamless switching between adapters is important to us. I figured it wasn't right of me to bitch without doing any work to fix it. So when 3.0 api gets discussed, I plan on being here. -- Tom Jenkins Development InfoStructure http://www.devis.com From fog@initd.org Thu Jun 20 13:06:30 2002 From: fog@initd.org (Federico Di Gregorio) Date: 20 Jun 2002 14:06:30 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <200206202149.12282@gnumed.net> References: <200206202149.12282@gnumed.net> Message-ID: <1024574790.589.81.camel@momo> --=-qb5xDeIdeBZgtiaWNPJL Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On Thu, 2002-06-20 at 13:49, Horst Herb wrote: > We wanted to make our project independend of database backends, or at lea= st=20 > of database adapters as it is supposed to be truly multi platform and mos= t=20 > adapters aren't. >=20 > We thought DB-API was a great idea. That is, until we tried....: IMHO, the target of the dbapi is *not* providing unchanged-source portability across the differet drivers implementing it. it is just to provide a common api: learn one, use many. > 1.) Connection strings incompatible between the 3 "most popular" Postgres= =20 > adatpters - easy enough to fix, just a few "if....then..else" > However, becomes tedious if you have hundreds of connections :-(( write a single wrapper function to do the connects =20 > 2.) Returned date formats incompatible despite all of them using mxDateTi= me write your own wrapper. or simpy choose the best-for-you adapter and stick to it. even better, write an abstractio layer atop of dbapi and release it to the public. you'll help other people solve the same problems you're experiencing now. > 3.) Frustrated, we gave up further tests for now. >=20 > Are we doing something wrong or are the specifications that ambiguous tha= t=20 > not even these simple issues can remain compatible? > Am I rightfully disappointed or are changes already on the way? hope this helps, federico --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org La felicit=E0 =E8 una tazza di cioccolata calda. Sempre. -- I= o --=-qb5xDeIdeBZgtiaWNPJL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9EcVGvcCgrgZGjesRAvRyAKCi1LQBqLyIHAxq7xSj53W3+qd9wgCgoat9 1BeufHBXLbnxjrYBPofKjko= =Ep/T -----END PGP SIGNATURE----- --=-qb5xDeIdeBZgtiaWNPJL-- From tjenkins@devis.com Thu Jun 20 13:09:40 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 20 Jun 2002 08:09:40 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024574790.589.81.camel@momo> References: <1024574790.589.81.camel@momo> Message-ID: <1024574980.583.129.camel@asimov> Hi Federico, On Thu, 2002-06-20 at 08:06, Federico Di Gregorio wrote: > On Thu, 2002-06-20 at 13:49, Horst Herb wrote: > > We wanted to make our project independend of database backends, or at > least > > of database adapters as it is supposed to be truly multi platform and > most > > adapters aren't. > > > > We thought DB-API was a great idea. That is, until we tried....: > > IMHO, the target of the dbapi is *not* providing unchanged-source > portability across the differet drivers implementing it. it is just to > provide a common api: learn one, use many. hrmmm, that's interesting opinion, but isn't it contradictory? a common api but yet you have to change source code to switch between drivers? please don't take that as a flame, you (should) know that i have utmost respect for you. -- Tom Jenkins Development InfoStructure http://www.devis.com From fog@initd.org Thu Jun 20 13:27:11 2002 From: fog@initd.org (Federico Di Gregorio) Date: 20 Jun 2002 14:27:11 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024574980.583.129.camel@asimov> References: <1024574790.589.81.camel@momo> <1024574980.583.129.camel@asimov> Message-ID: <1024576031.6772.7.camel@momo> --=-DVBkBoZ++YYKAmbCZ0EJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-06-20 at 14:09, Tom Jenkins wrote: > Hi Federico, >=20 > On Thu, 2002-06-20 at 08:06, Federico Di Gregorio wrote: > > On Thu, 2002-06-20 at 13:49, Horst Herb wrote: > > > We wanted to make our project independend of database backends, or at > > least=20 > > > of database adapters as it is supposed to be truly multi platform and > > most=20 > > > adapters aren't. > > >=20 > > > We thought DB-API was a great idea. That is, until we tried....: > >=20 > > IMHO, the target of the dbapi is *not* providing unchanged-source > > portability across the differet drivers implementing it. it is just to > > provide a common api: learn one, use many. >=20 > hrmmm, that's interesting opinion, but isn't it contradictory? a common > api but yet you have to change source code to switch between drivers? if you use the LIMIT keyword in postgresql, your code won't be portable to other adapters anyway. SQL shall be standard but too many backends implements their own extensions, not to talk about system tables, etc. the best thing you can do is, imho, build a layer above the dbapi, but that will force you to use only the mcd subset of sql available to all backends. > please don't take that as a flame, you (should) know that i have utmost > respect for you. no flame, sure ;) --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Don't dream it. Be it. -- Dr. Frank'n'further --=-DVBkBoZ++YYKAmbCZ0EJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9EcofvcCgrgZGjesRAg4AAJ4+XsEqfC5V65C/iGrFIrk/oiCDhgCgufbO fCayHRfR1vVoG3MfRL6MMws= =AIBb -----END PGP SIGNATURE----- --=-DVBkBoZ++YYKAmbCZ0EJ-- From jacobs@penguin.theopalgroup.com Thu Jun 20 13:27:22 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Thu, 20 Jun 2002 08:27:22 -0400 (EDT) Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <200206202149.12282@gnumed.net> Message-ID: Hi Horst; I've been down the same road you have, and despite some early disappointments with DB-API, I've had very good results in the long term. Our solution was to develop an abstraction/compatibility layer over the various native DB-API drivers. This allows is to smooth over many of the problems, without complicating our application code. On Thu, 20 Jun 2002, Horst Herb wrote: > We thought DB-API was a great idea. That is, until we tried....: > > 1.) Connection strings incompatible between the 3 "most popular" Postgres > adatpters - easy enough to fix, just a few "if....then..else" > However, becomes tedious if you have hundreds of connections :-(( We put a connection configuration system in place that could generate the various connection strings/arguments for the various adapters. All we specify is an opaque "DSN name" and the appropriate connection is returned. That way, all of the compatbility logic is nicely partitioned and can be updated easily. Plus, you don't have to look at millions of "if....then..else" statements everywhere. > 2.) Returned date formats incompatible despite all of them using mxDateTime We've not this particular problems with dates (and we use a great deal of them). Can you give me an example? > 3.) Frustrated, we gave up further tests for now. > > Are we doing something wrong or are the specifications that ambiguous that > not even these simple issues can remain compatible? > Am I rightfully disappointed or are changes already on the way? I hate to say it, but there is a huge amount of (possibly) unnecessary implementation freedom in DB-API 2.0, and a great deal of variation in the quality of implementation of DB-API drivers. After the frustration wears off, most just put on their engineer's hat and trudge forward. Here are the things we thought were important and are built into our DB-API driver abstraction layer: 1) String and identifier quoting and normalization. This is _really_ important, since every backend does something different. Some case-normalize identifiers to upper-case, some to lower-case, some don't need any case-normalization for quoted identifiers. Once you know how to normalize identifiers, you can then implement the wildly variable identifier quoting rules. 2) Generic date and time formatting. The DB-API mandated conversion functions to/from unix "seconds since epoch" is a waste of time. We deal with dates that fall before and after the epoch, so we need to supply our own constructors. (Also, mxDateTime and most DB-API drivers ignore time-zone information, which is something that I think _is_ a problem with DB-API -- since when is data-loss in a driver acceptable?!.) 3) Unified exception framework -- you want to be able to catch DB-API exceptions in code that does not know which driver will be generating them. Do not underestimate the importance of this! There are many approaches to solving this problem -- we have one, though it is a somewhat sticky problem. 4) SQL dialect translation -- this is not for casual applications, but we've implemented an SQL source-to-source translator that can parse several SQL dialects and output them to other SQL dialects. This process is far from perfected, but it is extensible and has made a huge difference in allowing us to write generic queries. These are just the issues that come to mind at the moment. We (i.e., my company) is preparing much of our framework for an open-source release. It is slow going, since we have a lot of code -- some we can release, some we can't -- and many lawyers to deal with. Hopefully we'll have something within the next 6 months to a year. Good luck, -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From andy@dustman.net Thu Jun 20 14:18:08 2002 From: andy@dustman.net (Andy Dustman) Date: 20 Jun 2002 09:18:08 -0400 Subject: [DB-SIG] Quoting table and column names In-Reply-To: <200206191419.48561.chris@cogdon.org> References: <4.3.2.7.2.20020619140133.00b5b408@inkt-3.inktomi.com> <200206191419.48561.chris@cogdon.org> Message-ID: <1024579088.1548.2.camel@4.0.0.10.in-addr.arpa> On Wed, 2002-06-19 at 17:19, Chris Cogdon wrote: > On Wednesday 19 June 2002 14:18, Ryan Weisenberger wrote: > > > Is it safe to ALWAYS quote table names and column names in SQL > > statements? My python app queries against several different kinds of > > databases, most notably Oracle 8 and 9, MS SQL Server 2000, and > > Sybase. When table and column names contain spaces or characters (':' or > > '-'), I surround them with double quotes. So is it safe to always do > > this? I thought at one time I discovered that some dbs don't like this. > > This is DBSS specific. > > For example, Postgresql requires you to use single quotes when you want to > generate a string literal, and double quotes when you need to quote an entity > name (column, table, etc) that has spaces in it. > > However, MySQL decide to not follow SQL standards, and lets you use single or > double quotes to specify string literals, and you need to use backticks to > quote an entity name (Can you see my anti-MySQL bias, here? :) True, up to a point: http://www.mysql.com/doc/L/e/Legal_names.html Note that the rules changed starting with MySQL Version 3.23.6 when we introduced quoting of identifiers (database, table, and column names) with ``'. `"' will also work to quote identifiers if you run in ANSI mode. See section 1.7.2 Running MySQL in ANSI Mode. http://www.mysql.com/doc/A/N/ANSI_mode.html If you start mysqld with the --ansi option, the following behavior of MySQL Server changes: * || is string concatenation instead of OR. * You can have any number of spaces between a function name and the `('. This forces all function names to be treated as reserved words. * `"' will be an identifier quote character (like the MySQL Server ``' quote character) and not a string quote character. * REAL will be a synonym for FLOAT instead of a synonym for DOUBLE. * The default transaction isolation level is SERIALIZABLE. See section 6.7.3 SET TRANSACTION Syntax. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From andy@dustman.net Thu Jun 20 14:47:51 2002 From: andy@dustman.net (Andy Dustman) Date: 20 Jun 2002 09:47:51 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024574095.583.113.camel@asimov> References: <200206202149.12282@gnumed.net> <1024574095.583.113.camel@asimov> Message-ID: <1024580871.10975.19.camel@4.0.0.10.in-addr.arpa> On Thu, 2002-06-20 at 07:54, Tom Jenkins wrote: > On Thu, 2002-06-20 at 07:49, Horst Herb wrote: > > We thought DB-API was a great idea. That is, until we tried....: > > > > 1.) Connection strings incompatible between the 3 "most popular" Postgres > > adatpters - easy enough to fix, just a few "if....then..else" > > However, becomes tedious if you have hundreds of connections :-(( Perhaps it would have been better, in retrospect, to require arguments similar to MySQLdb, i.e. connect(host=None, user=None, password=None, **kwargs) and then the connect would construct a DSN or whatever from those arguments, including any keyword arguments that define non-standard things. I will admit to arguing for the current situation, however. > > 2.) Returned date formats incompatible despite all of them using mxDateTime I have trouble understanding why this should be, if they are all using mxDateTime. Do they not all return DateTime instances? > Same thing here Horst. Also exception handling is difficult as each has > their own exception types. This should be fixed somewhat by the recent optional extensions to DB-API v2 which add the exceptions to the connection and cursor instances. Even then, MySQLdb.IntegrityError != psycopg.IntegrityError. Would the solution be to have a standard DBException module which defines these exceptions? These exceptions would need to be imported into each database module (though not exported); I doubt they will ever be "standard" exceptions (in the exceptions module). Since usually these exceptions are raised in C code, that would require some implementation work, although _mysql (the C portion of MySQLdb) already imports it's exceptions from a separate module (_mysql_exceptions). -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From jacobs@penguin.theopalgroup.com Thu Jun 20 15:05:06 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Thu, 20 Jun 2002 10:05:06 -0400 (EDT) Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024580871.10975.19.camel@4.0.0.10.in-addr.arpa> Message-ID: On 20 Jun 2002, Andy Dustman wrote: > Would the solution be to have a standard DBException module which > defines these exceptions? These exceptions would need to be imported > into each database module (though not exported); I doubt they will ever > be "standard" exceptions (in the exceptions module). Since usually these > exceptions are raised in C code, that would require some implementation > work, although _mysql (the C portion of MySQLdb) already imports it's > exceptions from a separate module (_mysql_exceptions). That is one solution -- probably the optimal solution. In the mean time we create a set of "virtualized" exceptions are patched into all the active drivers. This is how we do it: # Define our own virtual exception names and classes dbapi_exceptions = [ 'Warning', 'Error', 'InterfaceError', 'DatabaseError', 'DataError', 'OperationalError', 'IntegrityError', 'InternalError', 'ProgrammingError', 'NotSupportedError' ] class Warning (StandardError) : pass class Error (StandardError) : pass class InterfaceError (Error) : pass class DatabaseError (Error) : pass class DataError (DatabaseError) : pass class OperationalError (DatabaseError) : pass class IntegrityError (DatabaseError) : pass class InternalError (DatabaseError) : pass class ProgrammingError (DatabaseError) : pass class NotSupportedError (DatabaseError) : pass def _virtualize_exceptions(module): for e in dbapi_exceptions: driver_exception = getattr(module, e) global_exception = globals()[e] driver_exception.__bases__ += (global_exception,) _virtualize_exceptions(MySQLdb) _virtualize_exceptions(MSSQL) _virtualize_exceptions(PgSQL) _virtualize_exceptions(PoPy) _virtualize_exceptions(psycopg) # ... etc ... Of course, this approach relies on being able to change base classes of the module exceptions. Some extra work will be needed make this work when DB-API drivers start to use new-style classes for exceptions. -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From tjenkins@devis.com Thu Jun 20 15:11:43 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 20 Jun 2002 10:11:43 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: References: Message-ID: <1024582303.652.135.camel@asimov> On Thu, 2002-06-20 at 10:05, Kevin Jacobs wrote: > On 20 Jun 2002, Andy Dustman wrote: > > Would the solution be to have a standard DBException module which > > defines these exceptions? These exceptions would need to be imported > > into each database module (though not exported); I doubt they will ever > > be "standard" exceptions (in the exceptions module). Since usually these > > exceptions are raised in C code, that would require some implementation > > work, although _mysql (the C portion of MySQLdb) already imports it's > > exceptions from a separate module (_mysql_exceptions). > > That is one solution -- probably the optimal solution. In the mean time we yes this seems like a good solution. i wouldn't expect the DBException module to be grafted into the exceptions module. > create a set of "virtualized" exceptions are patched into all the active > drivers. This is how we do it: > wow, didn't think of that. if you don't mind, i may stea^H^H^H^Hstart using this code -- Tom Jenkins Development InfoStructure http://www.devis.com From jacobs@penguin.theopalgroup.com Thu Jun 20 15:35:03 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Thu, 20 Jun 2002 10:35:03 -0400 (EDT) Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024582303.652.135.camel@asimov> Message-ID: On 20 Jun 2002, Tom Jenkins wrote: > > create a set of "virtualized" exceptions are patched into all the active > > drivers. This is how we do it: > > > > > wow, didn't think of that. if you don't mind, i may stea^H^H^H^Hstart > using this code No problem -- I'm happy to contribute that idea to the public domain. You may want to include an attribution along with that code, if for no other reason so that you have someone to blame when it breaks when exceptions become new-style classes (and more importantly, I'll have a fix for it by then!). -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com From dustin@spy.net Thu Jun 20 17:25:50 2002 From: dustin@spy.net (Dustin Sallings) Date: Thu, 20 Jun 2002 09:25:50 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024574095.583.113.camel@asimov> Message-ID: Around 07:54 on Jun 20, 2002, Tom Jenkins said: # Same thing here Horst. Also exception handling is difficult as each has # their own exception types. # # This is one of the reasons why I'm now subscribed on this list. We're a # big postgres & python company (with Access mixed in ). Having # seamless switching between adapters is important to us. # # I figured it wasn't right of me to bitch without doing any work to fix # it. So when 3.0 api gets discussed, I plan on being here. Not to sound all AOLish, but this is my exact experience. I came to python from Java, and I've found that many of the APIs seem much less well designed. Honestly, I believe the python community should try to leverage some of the design from JDBC. All exception types are covered, there's no ambiguity (hard to write a DB indepdent lib when you have to figure out at runtime which of the five quoting styles the driver wants and have queries and code ready to deal with each one). I think a good start would be telling the drivers exactly what to do in any given circumstance rather than leaving it up to the developer to decide. It would be nice, for example, if thread safety were clearly defined for all modules rather than giving the driver developer a choice of options. I also believe a proper resultset object would be a huge improvement over list results. I saw a proposal come through here that looked pretty good, but it still allowed ambiguity (result rows were accessible via __getitem__ *or* direct attributes on the row, I think the latter is a bad idea because it wouldn't work in all situations). Unfortunately, I haven't had the time to implement what I think would make life easier yet. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From tjenkins@devis.com Thu Jun 20 17:27:42 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 20 Jun 2002 12:27:42 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: References: Message-ID: <1024590463.583.157.camel@asimov> On Thu, 2002-06-20 at 12:25, Dustin Sallings wrote: > # I figured it wasn't right of me to bitch without doing any work to fix > # it. So when 3.0 api gets discussed, I plan on being here. > > Not to sound all AOLish, but this is my exact experience. I came > to python from Java, and I've found that many of the APIs seem much less > well designed. Honestly, I believe the python community should try to Hrmm... interesting, i also came to python via java. i wonder if this issue is a stickler for the folks with java background? > > I also believe a proper resultset object would be a huge > improvement over list results. I saw a proposal come through here that > looked pretty good, but it still allowed ambiguity (result rows were > accessible via __getitem__ *or* direct attributes on the row, I think the > latter is a bad idea because it wouldn't work in all situations). > well, if i need to i use dtuple (http://www.lyra.org/greg/python/dtuple.py) which does what you want. Sometimes i just don't need a resultset object, and the returned tuple is just fine (not to mention faster). this btw caused a bit of trouble, pyscopg returns tuples, but pypgsql returns there own result object unless you set a flag. dtuple expects a tuple (iirc) so that was another change i had to set -- Tom Jenkins Development InfoStructure http://www.devis.com From jmunoz@telefonica.net Thu Jun 20 19:11:35 2002 From: jmunoz@telefonica.net (=?ISO-8859-1?Q?Juli=E1n_Mu=F1oz?=) Date: Thu, 20 Jun 2002 18:11:35 +0000 (GMT) Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: Message-ID: It seems that a multilayer architecture like the one you have done is a good solution (and I think the more natural), for the driver developpers and for the end users (developpers who write applications), and if some day it is released, and documented, it will be very nice. --=20 __o _ \<_ (_)/(_) Saludos de Juli=E1n EA4ACL -.- From gerhard.haering@gmx.de Thu Jun 20 20:13:27 2002 From: gerhard.haering@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Thu, 20 Jun 2002 21:13:27 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024590463.583.157.camel@asimov> References: <1024590463.583.157.camel@asimov> Message-ID: <20020620191327.GA1589@lilith.my-fqdn.de> * Tom Jenkins [2002-06-20 12:27 -0400]: > well, if i need to i use dtuple > (http://www.lyra.org/greg/python/dtuple.py) which does what you want. > Sometimes i just don't need a resultset object, and the returned tuple > is just fine (not to mention faster). > > this btw caused a bit of trouble, pyscopg returns tuples, but pypgsql > returns there own result object unless you set a flag. dtuple expects a > tuple (iirc) so that was another change i had to set Interesting. Does dtuple still have advantages over pyPgSQL's PgResultset in version 2.1? (I've optimized PgResultSet a lot for 2.1) And I hope I can optimize cursor fetches a lot more by splitting the current Cursor class into several mixins a la MySQLdb. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From dustin+pydbsig@spy.net Thu Jun 20 20:14:27 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Thu, 20 Jun 2002 12:14:27 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: Message-ID: Around 18:11 on Jun 20, 2002, Julián Muñoz said: # It seems that a multilayer architecture like the one you have done is a # good solution (and I think the more natural), for the driver developpers # and for the end users (developpers who write applications), and if some # day it is released, and documented, it will be very nice. I would argue that creating a less ambiguous DB API would prevent people from having to create such abstractions in the first place. I don't really understand the point of a DB API that requires another layer of abstraction before a programmer can begin to use it. The abstract interface maintainer must be aware of every driver that gets written and write custom code to deal with it, and then where are you? -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From tjenkins@devis.com Thu Jun 20 20:19:44 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 20 Jun 2002 15:19:44 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <20020620191327.GA1589@lilith.my-fqdn.de> References: <1024590463.583.157.camel@asimov> <20020620191327.GA1589@lilith.my-fqdn.de> Message-ID: <1024600784.13271.13.camel@asimov> On Thu, 2002-06-20 at 15:13, Gerhard H=E4ring wrote: > * Tom Jenkins [2002-06-20 12:27 -0400]: > > well, if i need to i use dtuple > > (http://www.lyra.org/greg/python/dtuple.py) which does what you want.=20 > > Sometimes i just don't need a resultset object, and the returned tuple > > is just fine (not to mention faster). > >=20 > > this btw caused a bit of trouble, pyscopg returns tuples, but pypgsql > > returns there own result object unless you set a flag. dtuple expects = a > > tuple (iirc) so that was another change i had to set >=20 > Interesting. Does dtuple still have advantages over pyPgSQL's > PgResultset in version 2.1? (I've optimized PgResultSet a lot for 2.1) > And I hope I can optimize cursor fetches a lot more by splitting the > current Cursor class into several mixins a la MySQLdb. >=20 well, i do a bunch of pg -> access; access -> pg stuff and i use dtuple with odbc, ado and pg drivers. since i share alot of the code between the pg and odbc/ado, PgResultSet does not help me at all. --=20 Tom Jenkins Development InfoStructure http://www.devis.com From mal@lemburg.com Thu Jun 20 21:35:46 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 20 Jun 2002 22:35:46 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: Message-ID: <3D123CA2.905@lemburg.com> > Around 18:11 on Jun 20, 2002, Juli?n Mu?oz said: > > # It seems that a multilayer architecture like the one you have done is a > # good solution (and I think the more natural), for the driver developpers > # and for the end users (developpers who write applications), and if some > # day it is released, and documented, it will be very nice. > > I would argue that creating a less ambiguous DB API would prevent > people from having to create such abstractions in the first place. I > don't really understand the point of a DB API that requires another layer > of abstraction before a programmer can begin to use it. The abstract > interface maintainer must be aware of every driver that gets written and > write custom code to deal with it, and then where are you? Just curious: have you ever used one of the DB API module yourself ? It is because of the DB API standard we have in Python that there are so mance different database interfaces around. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From dustin+pydbsig@spy.net Thu Jun 20 22:20:49 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Thu, 20 Jun 2002 14:20:49 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D123CA2.905@lemburg.com> Message-ID: Around 22:35 on Jun 20, 2002, M.-A. Lemburg said: # > I would argue that creating a less ambiguous DB API would prevent # > people from having to create such abstractions in the first place. I # > don't really understand the point of a DB API that requires another layer # > of abstraction before a programmer can begin to use it. The abstract # > interface maintainer must be aware of every driver that gets written and # > write custom code to deal with it, and then where are you? # # Just curious: have you ever used one of the DB API module yourself ? # # It is because of the DB API standard we have in Python that there are so # mance different database interfaces around. Yes I have, and I've used a couple of different modules under it. I understand that it's progress from having nothing to conform to at all, but it's still ambiguous enough that people are writing wrappers to access databases generically. That connection strings were not defined in the spec made it a bit difficult for me to get going at first, and I was just playing with a couple of drivers. Trying to create an application that is database independent cannot be done using the DB API spec, it's got to be wrapped with driver-specific code. I'm not saying the DB API is the wrong direction, it's certainly helping, but it needs to get rid of ambiguities and fill in some blanks. Any place where there's room for the developer to make decisions that affect the way the API is used makes it difficult to write code against the API. Options are only good if they're all required (i.e. the five quoting techniques). That is to say, options for the user of the driver, not for the developer of the driver. Now, there may very well be cases where behavior must be optional, but there needs to be a good reason. rollback() on a connection is reasonable because some people still use mySQL or similar DBs that don't inherently support transactions, but the paramstyle is just obscene. So, yeah, there are lots of drivers, but you have to learn how to use each one at least slightly differently. As long as this occurs, and as long as people have to change code when switching drivers, the API is insufficient. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From tjenkins@devis.com Thu Jun 20 23:39:08 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 20 Jun 2002 18:39:08 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: References: Message-ID: <1024612749.13287.53.camel@asimov> On Thu, 2002-06-20 at 17:20, Dustin Sallings wrote: > Around 22:35 on Jun 20, 2002, M.-A. Lemburg said: > # > # Just curious: have you ever used one of the DB API module yourself ? > # > # It is because of the DB API standard we have in Python that there are so > # mance different database interfaces around. > > Yes I have, and I've used a couple of different modules under it. > I understand that it's progress from having nothing to conform to at all, > but it's still ambiguous enough that people are writing wrappers to access > databases generically. > If it wasn't clear, I'm happy that there was progress to DBAPI 2. I picked up python as DBAPI 2 came out. It is usable, especially if you only work with one adapter. paramstyle (forgot about this one) - this was another one that got us. letting driver developers pick from a set of paramstyles means a hodge-podge of implemented paramstyles. we generate alot of our sql, so this becomes another extra step to make sure our generated paramstyle matches the style for the adapter we're using. is there a reason there are 5 different styles? can we narrow this down to maybe one? i don't have any problem with driver developers adding extra custom methods (ala pyscopg's dictfetchXXX). if i use a custom method then i'm taking responsibility. -- Tom Jenkins Development InfoStructure http://www.devis.com From vcladmins@ctrl-c.liu.se Thu Jun 20 23:53:04 2002 From: vcladmins@ctrl-c.liu.se (Ch'marr) Date: Thu, 20 Jun 2002 15:53:04 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024612749.13287.53.camel@asimov> References: <1024612749.13287.53.camel@asimov> Message-ID: <200206201553.04691.chmarr@furry.org.au> On Thursday 20 June 2002 15:39, Tom Jenkins wrote: > paramstyle (forgot about this one) - this was another one that got us. > letting driver developers pick from a set of paramstyles means a > hodge-podge of implemented paramstyles. we generate alot of our sql, s= o > this becomes another extra step to make sure our generated paramstyle > matches the style for the adapter we're using. is there a reason there > are 5 different styles? can we narrow this down to maybe one? Not to blow my own horn /too/ loudly, but this was something I mentioned = some=20 time ago. At the time, I added that it would be nice to, say, be able to write a dr= iver=20 that supported one param style (say, the one that the C interface layer=20 supported best), and have a DBI base layer do all the necessary conversio= ns=20 for the other param styles, so that the application programmer need only = pick=20 a paramstyle most suited to the application. --=20 ("`-/")_.-'"``-._ Ch'marr, a.k.a. . . `; -._ )-;-,_`) Chris Cogdon (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' VCL Co-administrator ((,.-' ((,/ fL From andy@dustman.net Fri Jun 21 00:45:43 2002 From: andy@dustman.net (Andy Dustman) Date: 20 Jun 2002 19:45:43 -0400 Subject: [DB-SIG] MySQLdb-0.9.2 release candidate 1 Message-ID: <1024616743.10975.30.camel@4.0.0.10.in-addr.arpa> There's actually quite a bit more in here than I would like in a release candidate; I seriously considered making this another beta, but my own testing seems to indicate that it's stable. The release notes are here: http://sourceforge.net/project/shownotes.php?release_id=95924 Most interesting tidbits: * _mysql.connection and .result objects which can be used as new-style base classes in Python 2.2 or newer * Greatly expanded internal documentation (for pydoc) * Improved unicode and blob/array support * Package name mimics python.org RPM naming convention * A sprinkling of bug fixes Get it here: http://sourceforge.net/project/showfiles.php?group_id=22307&release_id=95924 -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From dustin+pydbsig@spy.net Fri Jun 21 00:52:47 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Thu, 20 Jun 2002 16:52:47 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <200206201553.04691.chmarr@furry.org.au> Message-ID: Around 15:53 on Jun 20, 2002, Ch'marr said: # At the time, I added that it would be nice to, say, be able to write a # driver that supported one param style (say, the one that the C interface # layer supported best), and have a DBI base layer do all the necessary # conversions for the other param styles, so that the application # programmer need only pick a paramstyle most suited to the application. This sounds reasonable. I like the 'pyformat' style, but 'qmark' can have special meaning that could optimize queries quite a bit. It'd be great to get both. Just to be clear, I don't mind that there are five styles, just that the driver developer gets to pick one instead of the user. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From andy@dustman.net Fri Jun 21 01:35:26 2002 From: andy@dustman.net (Andy Dustman) Date: 20 Jun 2002 20:35:26 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <1024612749.13287.53.camel@asimov> References: <1024612749.13287.53.camel@asimov> Message-ID: <1024619726.13932.3.camel@4.0.0.10.in-addr.arpa> On Thu, 2002-06-20 at 18:39, Tom Jenkins wrote: > paramstyle (forgot about this one) - this was another one that got us. > letting driver developers pick from a set of paramstyles means a > hodge-podge of implemented paramstyles. we generate alot of our sql, so > this becomes another extra step to make sure our generated paramstyle > matches the style for the adapter we're using. is there a reason there > are 5 different styles? can we narrow this down to maybe one? Sure, as long as it's %s, and then the driver can map in the correct placeholder with the % string formatting operator, since the placeholder determined by the database vendor and not by the module author unless the database doesn't support placeholders and parameter binding to begin with; most do, though MySQL and PostgreSQL don't. Example: If the implementation uses qmark (?), substitute them in with query % ['?']*len(params) -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From matt@zope.com Fri Jun 21 01:45:08 2002 From: matt@zope.com (Matthew T. Kromer) Date: Thu, 20 Jun 2002 20:45:08 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 References: Message-ID: <3D127714.7070704@zope.com> Dustin Sallings wrote: >Around 15:53 on Jun 20, 2002, Ch'marr said: > ># At the time, I added that it would be nice to, say, be able to write a ># driver that supported one param style (say, the one that the C interface ># layer supported best), and have a DBI base layer do all the necessary ># conversions for the other param styles, so that the application ># programmer need only pick a paramstyle most suited to the application. > > This sounds reasonable. I like the 'pyformat' style, but 'qmark' >can have special meaning that could optimize queries quite a bit. It'd be >great to get both. > > Just to be clear, I don't mind that there are five styles, just >that the driver developer gets to pick one instead of the user. > Keep in mind for any driver that wants do do binding (bind by name, bind by position) formats like 'pyformat' require some degree of monkey work. The reason being that the DRIVER needs to be in control of the TYPE of insert into the bind string... most of the time, it needs to turn the query expression into querystring + bind_list ... but the bind "names" in the query string may be '?' or ':1' or ':name' or many other variants. Most of the time doing any kind of parameter insert into the query string to generate a bind name is a string insert -- which means you have to process the query string to convert the types first! Aaaargh. I hate pyformat for that reason. N.B. if your RDBMS supports real binds, string quoting is usually much less of an issue; the quote either comes directly from a human being, or the data originates via program and is bound rather than converted into a string and executed as part of the SQL command text. I'd be more in favor of some type of driver-provided "query builder" interface, which could build up a query object in an agnostic fashion that met its own needs. I also have to chuckle every time someone wants a "purely generic" interface. Most RDBMS have divergent SQL dialects, with divergent types. Any "power user" usually is tied to a specific RDBMS and wants to maximize it, and thus is going to get very frustrated when there is no "generic" way to access a very specific feature. As far as people's DateTime problems go -- I certainly understand the frustration. I know I had a conversation with PythonLabs some time ago (Christmas?) where the notion of creating some kind of official "time" object was bounced around again. I don't remember what the outcome was though; other than there is a lot of quicksand when dealing with people's expectations of what "Time" is. As a driver author, I'm *extremely* reluctant to introduce a dependance on yet another piece of code, which is one reason I would appreciate an official Python DateTime object (for most RDBMS purposes, said object probably needs to have a date range of +/-10,000 years, and have precision down to the millisecond -- but that is not precise enough for some scientific purposes!) From dustin+pydbsig@spy.net Fri Jun 21 07:27:23 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Thu, 20 Jun 2002 23:27:23 -0700 (PDT) Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D127714.7070704@zope.com> Message-ID: Around 20:45 on Jun 20, 2002, Matthew T. Kromer said: # I also have to chuckle every time someone wants a "purely generic" # interface. Most RDBMS have divergent SQL dialects, with divergent # types. Any "power user" usually is tied to a specific RDBMS and wants # to maximize it, and thus is going to get very frustrated when there is # no "generic" way to access a very specific feature. JDBC does a great job here. Regardless of dialect, queries are always sent the same way to the backend and most of the common database types are covered. And for your ``power users,'' there's this: OTHER The constant in the Java programming language that indicates that the SQL type is database-specific and gets mapped to a Java object that can be accessed via the methods getObject and setObject. That doesn't cover every strange thing a DB does, but for those really special-purpose things, you can always cast your Connection object to the specific class (postgres used to have to do this for BLOBs, but JDBC covers BLOBs in a standard way now). I just don't think it's OK to say that the API doesn't have to be common across drivers simply because there's a possibility to use non-portable SQL dialects. I encourage you to read through the classes in java.sql. I don't believe it needs to be entirely cloned, but it's extremely powerful from an application developer's point of view. It's unambiguous and leaves you with nothing to worry about but your SQL dialect. And it's even got facilities to tell you what specific features of the database supports. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From mal@lemburg.com Fri Jun 21 09:35:14 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 21 Jun 2002 10:35:14 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: Message-ID: <3D12E542.8090701@lemburg.com> Dustin Sallings wrote: > Around 22:35 on Jun 20, 2002, M.-A. Lemburg said: > > # > I would argue that creating a less ambiguous DB API would prevent > # > people from having to create such abstractions in the first place. I > # > don't really understand the point of a DB API that requires another layer > # > of abstraction before a programmer can begin to use it. The abstract > # > interface maintainer must be aware of every driver that gets written and > # > write custom code to deal with it, and then where are you? > # > # Just curious: have you ever used one of the DB API module yourself ? > # > # It is because of the DB API standard we have in Python that there are so > # mance different database interfaces around. > > Yes I have, and I've used a couple of different modules under it. > I understand that it's progress from having nothing to conform to at all, > but it's still ambiguous enough that people are writing wrappers to access > databases generically. This is on purpose: the DB API spec is intended to map as many different backend systems as possible. The only way to achieve this is by allowing a certain amount of freedom on the implementors side. BTW, if you want to support multiple DB backends, why not just use mxODBC ? It pretty much interfaces to all major databases out there and provides a consistent interface to all of them. > That connection strings were not defined in the spec made it a bit > difficult for me to get going at first, and I was just playing with a > couple of drivers. Trying to create an application that is database > independent cannot be done using the DB API spec, it's got to be wrapped > with driver-specific code. If you want to write database independent applications you have much more to do than just fiddle with the DB API interface. The SQL dialects and data types differ *very* much between databases. I'm even starting to talk about differences in semantics. The only way to work aroung this is by adding an abstraction layer which has to be application specific. > I'm not saying the DB API is the wrong direction, it's certainly > helping, but it needs to get rid of ambiguities and fill in some blanks. > Any place where there's room for the developer to make decisions that > affect the way the API is used makes it difficult to write code against > the API. Options are only good if they're all required (i.e. the five > quoting techniques). That is to say, options for the user of the driver, > not for the developer of the driver. I disagree. The freedom is needed so that you can support more than just one backend, e.g. a flat file database is likely to behave differently than a full blown SQL Server. > Now, there may very well be cases where behavior must be optional, > but there needs to be a good reason. rollback() on a connection is > reasonable because some people still use mySQL or similar DBs that don't > inherently support transactions, but the paramstyle is just obscene. Certainly not. If you would want to enforce a standard paramstyle then you'd have to add a parser to the modules that don't support the "standard" way of writing parameters defined by some DB API spec. > So, yeah, there are lots of drivers, but you have to learn how to > use each one at least slightly differently. As long as this occurs, and > as long as people have to change code when switching drivers, the API is > insufficient. Maybe for you, but not for the majority. The DB API has a very long success story. This is evidence enough for me that the approach was the right one. Again, if you don't like dealing with multiple different interface use mxODBC and talk to the database via ODBC. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From mal@lemburg.com Fri Jun 21 10:04:21 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 21 Jun 2002 11:04:21 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: Message-ID: <3D12EC15.2000901@lemburg.com> Dustin Sallings wrote: > Around 20:45 on Jun 20, 2002, Matthew T. Kromer said: > > # I also have to chuckle every time someone wants a "purely generic" > # interface. Most RDBMS have divergent SQL dialects, with divergent > # types. Any "power user" usually is tied to a specific RDBMS and wants > # to maximize it, and thus is going to get very frustrated when there is > # no "generic" way to access a very specific feature. > > JDBC does a great job here. Regardless of dialect, queries are > always sent the same way to the backend and most of the common database > types are covered. And for your ``power users,'' there's this: > > OTHER > > The constant in the Java programming language that indicates > that the SQL type is database-specific and gets mapped to a Java > object that can be accessed via the methods getObject and > setObject. > > That doesn't cover every strange thing a DB does, but for those > really special-purpose things, you can always cast your Connection object > to the specific class (postgres used to have to do this for BLOBs, but > JDBC covers BLOBs in a standard way now). > > I just don't think it's OK to say that the API doesn't have to be > common across drivers simply because there's a possibility to use > non-portable SQL dialects. > > I encourage you to read through the classes in java.sql. I don't > believe it needs to be entirely cloned, but it's extremely powerful from > an application developer's point of view. It's unambiguous and leaves you > with nothing to worry about but your SQL dialect. And it's even got > facilities to tell you what specific features of the database supports. That's what mxODBC gives you as well: a standard interface to all kinds of databases, including the catalog methods you mentioned. (Note that JDBC was modelled after ODBC.) I don't see a need to tweak the DB API and force this concept onto all other module writers. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From paul@boddie.net Fri Jun 21 10:55:35 2002 From: paul@boddie.net (paul@boddie.net) Date: 21 Jun 2002 09:55:35 -0000 Subject: [DB-SIG] Experiences with DB-API2.0 Message-ID: <20020621095535.1957.qmail@www2.nameplanet.com> Dustin Sallings wrote: > > That connection strings were not defined in the spec made it a bit >difficult for me to get going at first, and I was just playing with a >couple of drivers. Trying to create an application that is database >independent cannot be done using the DB API spec, it's got to be wrapped >with driver-specific code. Indeed. Even modules/drivers for the same database system (eg. pyPgSQL and psycopg) use different enough connection strings/parameters to make things "interesting" for developers. If one were porting stuff from PostgreSQL to MySQL then one might expect discomfort, but should it really be necessary to experience that "porting" to the same system? > Now, there may very well be cases where behavior must be optional, >but there needs to be a good reason. rollback() on a connection is >reasonable because some people still use mySQL or similar DBs that don't >inherently support transactions, but the paramstyle is just obscene. The standard response to the proliferation of paramstyles is that different databases expose different notations and that people who are used to those systems like to use their favourite notation. A somewhat more likely explanation is that it might be slightly easier for the module/driver developer to receive parameters in the native notation. In any case, JDBC ruled on a particular paramstyle and surely only the most die-hard of Oracle developers (for example) must still be complaining about it now; and I suspect that the most die-hard developers only use the vendor's tools, anyway, so should we really pay that much attention to them? "Matthew T. Kromer" wrote: > >I also have to chuckle every time someone wants a "purely generic" >interface. Most RDBMS have divergent SQL dialects, with divergent >types. Any "power user" usually is tied to a specific RDBMS and wants >to maximize it, and thus is going to get very frustrated when there is >no "generic" way to access a very specific feature. As far as I can see, just standardising the simple things like connection strings/parameters and paramstyles would help people out a lot. I doubt that anyone really expects their SQL statements to be translated, even though there's been some talk of that of late. Even so, for reasonably straightforward queries, most database systems have surely converged in terms of SQL standards support and have enough in common to support generic querying and updating. In other words, I don't think the full (but reasonable) potential of the DB-API has been realised yet. Paul From jno@glasnet.ru Fri Jun 21 12:05:16 2002 From: jno@glasnet.ru (Eugene V. Dvurechenski) Date: Fri, 21 Jun 2002 15:05:16 +0400 Subject: [DB-SIG] Quoting table and column names In-Reply-To: <4.3.2.7.2.20020619140133.00b5b408@inkt-3.inktomi.com> References: <4.3.2.7.2.20020619140133.00b5b408@inkt-3.inktomi.com> Message-ID: <20020621110516.GH14396@glas.net> nope. select * from dual where "dummy" = 'X' ORA-00904: invalid column name select * from dual where dummy = 'X' 'X' in Oracle you will get names case sensetive if quoted. -jno On Wed, Jun 19, 2002 at 02:18:14PM -0700, Ryan Weisenberger wrote: > Is it safe to ALWAYS quote table names and column names in SQL > statements? My python app queries against several different kinds of > databases, most notably Oracle 8 and 9, MS SQL Server 2000, and > Sybase. When table and column names contain spaces or characters (':' or > '-'), I surround them with double quotes. So is it safe to always do > this? I thought at one time I discovered that some dbs don't like this. > > Thanks, > Ryan > _________________________ > Ryan Weisenberger > Software Developer > ryanw@inktomi.com > (650) 653-4595 > _________________________ > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- SY, jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ] a TeleRoss techie [ http://www.aviation.ru/ ] If God meant man to fly, He'd have given him more money. From tjenkins@devis.com Fri Jun 21 14:43:52 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 21 Jun 2002 09:43:52 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D12E542.8090701@lemburg.com> References: <3D12E542.8090701@lemburg.com> Message-ID: <1024667033.13271.81.camel@asimov> On Fri, 2002-06-21 at 04:35, M.-A. Lemburg wrote: > Dustin Sallings wrote: > > > > I'm not saying the DB API is the wrong direction, it's certainly > > helping, but it needs to get rid of ambiguities and fill in some blanks. > > Any place where there's room for the developer to make decisions that > > affect the way the API is used makes it difficult to write code against > > the API. Options are only good if they're all required (i.e. the five > > quoting techniques). That is to say, options for the user of the driver, > > not for the developer of the driver. > > I disagree. > > The freedom is needed so that you can support > more than just one backend, e.g. a flat file database is likely > to behave differently than a full blown SQL Server. >From a driver developer's point of view, but not from an application developer's point of view. > > So, yeah, there are lots of drivers, but you have to learn how to > > use each one at least slightly differently. As long as this occurs, and > > as long as people have to change code when switching drivers, the API is > > insufficient. > > Maybe for you, but not for the majority. The DB API has a very > long success story. This is evidence enough for me that the > approach was the right one. I submit that version 1 is better than version 2. I also submit that version 2 is not the end-all, be-all. > > Again, if you don't like dealing with multiple different > interface use mxODBC and talk to the database via ODBC. > This would lock myself and my clients into a single commercial vendor solution. That is unacceptable. -- Tom Jenkins Development InfoStructure http://www.devis.com From dustin+pydbsig@spy.net Fri Jun 21 17:50:11 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Fri, 21 Jun 2002 09:50:11 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D12E542.8090701@lemburg.com> Message-ID: Around 10:35 on Jun 21, 2002, M.-A. Lemburg said: # This is on purpose: the DB API spec is intended to map as many different # backend systems as possible. The only way to achieve this is by allowing # a certain amount of freedom on the implementors side. # # BTW, if you want to support multiple DB backends, why not just use # mxODBC ? It pretty much interfaces to all major databases out there and # provides a consistent interface to all of them. How can you simultaneously argue that the DB API was intentionally designed ambiguously to allow as many backend systems as possible, and state that there's another driver API out there that supports ``pretty much all major databases'' that has a consistent interface? # If you want to write database independent applications you have much # more to do than just fiddle with the DB API interface. The SQL dialects # and data types differ *very* much between databases. I'm even starting # to talk about differences in semantics. The only way to work aroung this # is by adding an abstraction layer which has to be application specific. I believe that arguing that it's unimportant to keep B consistent because you'll probably have to change A anyway is invalid. Personally, I've rarely had to change my SQL when going between PostgreSQL and Sybase. When I do have to change a query for a specific database, I deal with that. My abstraction layer deals with that in such a way that I just have to drop the two queries in and it's good. However, this is all java code and I have never had to change the way I talk to the DB when switching between postgres and sybase. My abstraction layer doesn't have to do anything but select a query when they are different. # > I'm not saying the DB API is the wrong direction, it's certainly # > helping, but it needs to get rid of ambiguities and fill in some blanks. # > Any place where there's room for the developer to make decisions that # > affect the way the API is used makes it difficult to write code against # > the API. Options are only good if they're all required (i.e. the five # > quoting techniques). That is to say, options for the user of the driver, # > not for the developer of the driver. # # I disagree. # # The freedom is needed so that you can support more than just one # backend, e.g. a flat file database is likely to behave differently than # a full blown SQL Server. To me, that says you can't group fundamentally different things under a single API. # > Now, there may very well be cases where behavior must be optional, # > but there needs to be a good reason. rollback() on a connection is # > reasonable because some people still use mySQL or similar DBs that don't # > inherently support transactions, but the paramstyle is just obscene. # # Certainly not. If you would want to enforce a standard paramstyle then # you'd have to add a parser to the modules that don't support the # "standard" way of writing parameters defined by some DB API spec. So? A driver developer should be expected to write code. I've written this piece of code around a partial JDBC driver, it took me about fifteen minutes one day. # Maybe for you, but not for the majority. The DB API has a very long # success story. This is evidence enough for me that the approach was the # right one. Perl, VB, etc... all have success stories longer than the DB API, but that doesn't make me believe they were done correctly. I might believe the DB API were perfect if I hadn't used it and didn't see anyone else with the same complaints I've got about it. # Again, if you don't like dealing with multiple different interface use # mxODBC and talk to the database via ODBC. This statement reads as if you don't believe there is a DB API, and/or that the python community isn't capable of coming up with one (as opposed to what you said, ``multiple different interface[s]''). -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From magnus@thinkware.se Fri Jun 21 19:23:13 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Fri, 21 Jun 2002 20:23:13 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D12E542.8090701@lemburg.com> References: Message-ID: <5.1.0.14.0.20020621113010.024874f0@www.thinkware.se> First of all, I have a confession to make: I haven't really used the Python DB API extensively. I've built SQL applications for more than 10 years, but not seriously with Python. Ok, now that's cleared out. ;-) I think we might agree on some things: * It would be convenient for application programmers if they could write their programs in a more uniform and database independant way. Being able to swap databases with the smallest possible effort is a clear advantage. * Python database drivers are typically developed in economical conditions that are very different from those that are used to develop Java database drivers. (And possibly some people with Java roots don't realize that a slightly different tone is more productive in an open source environment.) * Making life easier for the database driver developer is probably a good way to improve the quality and quantity of Python database drivers. * It's a good thing if uniformity and convenience for the application programmer doesn't prevent using database specific features. * It would be good if uniformity and convenience could be achieved without placing additional burdens on the driver developers. Actually, if there was a standard abstraction layer on top of the DB API, I imagine some database drivers could be a bit thinner than they are today. An alternative or complement to another layer of abstraction on top of the DB API could be some kind of generic DB API library with code that would be useful to share between database drivers. For instance code for handling connection string conversion, date/time conversions, standard exceptions, param style conversions etc. I'm sure we can all agree that there is room for improvement, here as everywhere else. So how do we go about to achieve that? I think that it would be great if there was an SQL database driver using the DB API in the python standard library. The DB API is really a good thing to prevent too much chaos and variation, but with the database usage in the standard docs, and in the future in typical Python books and tutorials, as well as an example implementation, I think we would both boost new interest in python database usage, contribute to standardization and make it easier to create standard support code--whether it's helpful libraries for drivers to use, or abstraction layers on top. Maybe SQLite could be useful here? I have a dozen Python books in my book shelf. The only ones that cover the DB API is Hammond/Robinsons Win32 book and Holden's new Python Web Programming. I think we can agree that python database programming isn't as visible as it could be. I hope this will change though. M.-A. Lemburg wrote: >BTW, if you want to support multiple DB backends, why not >just use mxODBC ? It pretty much interfaces to all major >databases out there and provides a consistent interface to >all of them. I'm working as a consultant, and apart from the contract I've worked on for the last nine months (where I decided to use ZODB instead of a relational database), I've never been approached to do Python programming. Python has popped up in my projects on my initiative, like a grass roots effort. In this situation I think it would be much more difficult if commercial licences had been required. Free software is great in this respect. Last time I looked, I came to the conclusion that I'm not allowed to use mxODBC as a consultant unless my client gets a commercial licence. For me it would make a big difference if mxODBC had a dual licence like MySQL or SleepyCat's db. I think GPL would be ok in these situations. I surely appreciate that programmers want to earn money on their work. I know I do. But in the situation I am now, I'm often forced to select an open source (or at least free as in free beer) solution. As soon as a purchase has to be made, more decision makers are involved, and management will start to discuss policies etc. Maybe things are different in different countries and different corporate cultures, but I've had a lot of freedom to implement things the way I like as long as I don't require purchases to be made. Not for all kinds of software, but there have been a lot of opportunities to introduce Python for testing tools, analysis tools, troubleshooting, data conversion etc. >If you want to write database independent applications you >have much more to do than just fiddle with the DB API interface. >The SQL dialects and data types differ *very* much between >databases. I'm even starting to talk about differences in >semantics. The only way to work aroung this is by adding >an abstraction layer which has to be application specific. I've written applications (not using Python) that ran unchanged with Oracle 7, Gupta SQLBase and different versions of Informix. This requires some disciplin, and special handling of connect strings and access to system tables. But it worked pretty well. I'm sure 99% of the SQL statements were identical. In this case I used a product called JAM. (it's now called Panther, and is free on Linux, see www.possl.org. Unfortunately, programming in its language JPL feels like having your right hand tied behind your back if you are used to Python.) I've also used DB2, Access, Sybase, MySQL etc, and almost all the time I manage to restrict myself to using standard SQL constructs. >The freedom is needed so that you can support >more than just one backend, e.g. a flat file database is likely >to behave differently than a full blown SQL Server. Has anyone ever shown any interest in such a thing? There are a number of Python drivers for accessing flat files, but none that use the DB API that I heard of. Wouldn't a higher level of abstraction be more appropriate for a uniform access to flat files and SQL databases? I can't see a reason to discuss other types of databases than SQL databases (well, more or less SQL ;) when it concerns the DB API. There are a lot of constructs such as cursors etc that don't mean anything in most other types of databases. >Certainly not. If you would want to enforce a standard >paramstyle then you'd have to add a parser to the modules >that don't support the "standard" way of writing parameters >defined by some DB API spec. Maybe this is an effort that could be made once, and shared between drivers? >Maybe for you, but not for the majority. The DB API has a very >long success story. This is evidence enough for me that the >approach was the right one. Majority of what? Majority of actual users, or majority of people who could have been users? I'm greatful for the work that so many people have put into this, but I don't think we should deny that it could be much more accessible. I've programmed extensively in SQL since 1990 and in Python since 1996, but I've still never used any DB API driver beyond the ODBC driver in the Mark Hammond's Windows extensions. :-( This is partly because I've never desperately needed it, but it has happened a few times that I choose to popen shell scripts with SQL calls, or that I made SQL queries to text files which I processed in Python. If the threshold to use DB API comliant drivers had been lower, I'm pretty sure that's the way I would have gone. How ever we go about things, we can't expect the Python standard library to include binary versions of most popular databases on all the platforms Python supports. So there will always be a higher threshold to using SQL from Python than to use Python in general. It would be really great if an ODBC driver could be included in the standard library, but I suppose this is something I'll just have to dream about. As I said, I understand Marc-Andr=E9's position, but I can always dream, can't I? ;-) --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From mal@lemburg.com Fri Jun 21 19:24:45 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 21 Jun 2002 20:24:45 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: Message-ID: <3D136F6D.2060108@lemburg.com> Dustin Sallings wrote: > Around 10:35 on Jun 21, 2002, M.-A. Lemburg said: > > # This is on purpose: the DB API spec is intended to map as many different > # backend systems as possible. The only way to achieve this is by allowing > # a certain amount of freedom on the implementors side. > # > # BTW, if you want to support multiple DB backends, why not just use > # mxODBC ? It pretty much interfaces to all major databases out there and > # provides a consistent interface to all of them. > > How can you simultaneously argue that the DB API was intentionally > designed ambiguously to allow as many backend systems as possible, and > state that there's another driver API out there that supports ``pretty > much all major databases'' that has a consistent interface? I don't see your point. mxODBC implements DB API 2.0 and extends it with a lot of other interesting APIs which ODBC provides. All the standardization work is done (more or less) in the ODBC drivers. This allows mxODBC to provide a consistent interface to multiple databases. I don't see how this is in conflict with saying that an interface like the Python DB API needs to be flexible to allow for more than one backend. > # If you want to write database independent applications you have much > # more to do than just fiddle with the DB API interface. The SQL dialects > # and data types differ *very* much between databases. I'm even starting > # to talk about differences in semantics. The only way to work aroung this > # is by adding an abstraction layer which has to be application specific. > > I believe that arguing that it's unimportant to keep B consistent > because you'll probably have to change A anyway is invalid. Personally, > I've rarely had to change my SQL when going between PostgreSQL and Sybase. > When I do have to change a query for a specific database, I deal with > that. My abstraction layer deals with that in such a way that I just have > to drop the two queries in and it's good. However, this is all java code > and I have never had to change the way I talk to the DB when switching > between postgres and sybase. My abstraction layer doesn't have to do > anything but select a query when they are different. That's nice. Why don't you write a wrapper for Python that implements JDBC on top of all existing DB API interface ? > # > I'm not saying the DB API is the wrong direction, it's certainly > # > helping, but it needs to get rid of ambiguities and fill in some blanks. > # > Any place where there's room for the developer to make decisions that > # > affect the way the API is used makes it difficult to write code against > # > the API. Options are only good if they're all required (i.e. the five > # > quoting techniques). That is to say, options for the user of the driver, > # > not for the developer of the driver. > # > # I disagree. > # > # The freedom is needed so that you can support more than just one > # backend, e.g. a flat file database is likely to behave differently than > # a full blown SQL Server. > > To me, that says you can't group fundamentally different things > under a single API. That's Java-thinking. Python works in terms of interfaces and that's also how the DB API is designed, > # > Now, there may very well be cases where behavior must be optional, > # > but there needs to be a good reason. rollback() on a connection is > # > reasonable because some people still use mySQL or similar DBs that don't > # > inherently support transactions, but the paramstyle is just obscene. > # > # Certainly not. If you would want to enforce a standard paramstyle then > # you'd have to add a parser to the modules that don't support the > # "standard" way of writing parameters defined by some DB API spec. > > So? A driver developer should be expected to write code. I've > written this piece of code around a partial JDBC driver, it took me about > fifteen minutes one day. Great. If you can provide patches for all the Python drivers, I'm sure the authors would love to integrate them ;-) > # Maybe for you, but not for the majority. The DB API has a very long > # success story. This is evidence enough for me that the approach was the > # right one. > > Perl, VB, etc... all have success stories longer than the DB API, > but that doesn't make me believe they were done correctly. I might > believe the DB API were perfect if I hadn't used it and didn't see anyone > else with the same complaints I've got about it. Nothing is ever perfect, only good enough :-) Of course, there are things in the DB API that could be better, but it's pretty useful in its current state already, so there's really no need to try to talk it down. > # Again, if you don't like dealing with multiple different interface use > # mxODBC and talk to the database via ODBC. > > This statement reads as if you don't believe there is a DB API, > and/or that the python community isn't capable of coming up with one (as > opposed to what you said, ``multiple different interface[s]''). The strategy is different to what you have in mind: the DB API defines an API for database interfaces, not an interface to databases, like e.g. the Perl DBI concept. We don't have a driver - manager setup. It's only drivers. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From mal@lemburg.com Fri Jun 21 19:32:05 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 21 Jun 2002 20:32:05 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: <3D12E542.8090701@lemburg.com> <1024667033.13271.81.camel@asimov> Message-ID: <3D137125.1040901@lemburg.com> Tom Jenkins wrote: > On Fri, 2002-06-21 at 04:35, M.-A. Lemburg wrote: > >>Dustin Sallings wrote: >> >> >> >>> I'm not saying the DB API is the wrong direction, it's certainly >>>helping, but it needs to get rid of ambiguities and fill in some blanks. >>>Any place where there's room for the developer to make decisions that >>>affect the way the API is used makes it difficult to write code against >>>the API. Options are only good if they're all required (i.e. the five >>>quoting techniques). That is to say, options for the user of the driver, >>>not for the developer of the driver. >> >>I disagree. >> >>The freedom is needed so that you can support >>more than just one backend, e.g. a flat file database is likely >>to behave differently than a full blown SQL Server. > > >>From a driver developer's point of view, but not from an application > developer's point of view. But the application developer has the freedom of choice and that's only possible if there is something to choose from ;-) >>> So, yeah, there are lots of drivers, but you have to learn how to >>>use each one at least slightly differently. As long as this occurs, and >>>as long as people have to change code when switching drivers, the API is >>>insufficient. >> >>Maybe for you, but not for the majority. The DB API has a very >>long success story. This is evidence enough for me that the >>approach was the right one. > > > I admit that version 1 is better than version 2. I also admit that > version 2 is not the end-all, be-all. Certainly not. >>Again, if you don't like dealing with multiple different >>interface use mxODBC and talk to the database via ODBC. >> > > > This would lock myself and my clients into a single commercial vendor > solution. That is unacceptable. Depends on how you see this: mxODBC takes a lot of work off of your back, so there's less code to write, less support to invest, less debugging, etc. I was only providing you with a solution to what you think the problem is. As I said before: there is freedom of choice. In reality you'll rarely have to switch database backends for applications and if you do, you'll make sure that the effort needed to do this will be minimal (or well-payed ;-). I do believe that the existing Python database interfaces for the most common backends have high quality and provide you with very good and stable interfaces. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From mal@lemburg.com Fri Jun 21 20:31:35 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 21 Jun 2002 21:31:35 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: <5.1.0.14.0.20020621113010.024874f0@www.thinkware.se> Message-ID: <3D137F17.70605@lemburg.com> Magnus Lycka wrote: > M.-A. Lemburg wrote: >=20 >> BTW, if you want to support multiple DB backends, why not >> just use mxODBC ? It pretty much interfaces to all major >> databases out there and provides a consistent interface to >> all of them. >=20 >=20 > I'm working as a consultant, and apart from the contract I've > worked on for the last nine months (where I decided to use ZODB > instead of a relational database), I've never been approached to > do Python programming. Python has popped up in my projects on my > initiative, like a grass roots effort. In this situation I think > it would be much more difficult if commercial licences had been > required. Free software is great in this respect. >=20 > Last time I looked, I came to the conclusion that I'm not allowed to > use mxODBC as a consultant unless my client gets a commercial licence. > For me it would make a big difference if mxODBC had a dual licence like > MySQL or SleepyCat's db. I think GPL would be ok in these situations. I > surely appreciate that programmers want to earn money on their work. > I know I do. But in the situation I am now, I'm often forced to > select an open source (or at least free as in free beer) solution. >=20 > As soon as a purchase has to be made, more decision makers are > involved, and management will start to discuss policies etc. Maybe > things are different in different countries and different corporate > cultures, but I've had a lot of freedom to implement things the way > I like as long as I don't require purchases to be made. Not for all > kinds of software, but there have been a lot of opportunities to > introduce Python for testing tools, analysis tools, troubleshooting, > data conversion etc. I can understand that, but I run a business and have to pay for my pizza too :-) >> If you want to write database independent applications you >> have much more to do than just fiddle with the DB API interface. >> The SQL dialects and data types differ *very* much between >> databases. I'm even starting to talk about differences in >> semantics. The only way to work aroung this is by adding >> an abstraction layer which has to be application specific. >=20 >=20 > I've written applications (not using Python) that ran unchanged > with Oracle 7, Gupta SQLBase and different versions of Informix. > This requires some disciplin, and special handling of connect > strings and access to system tables. But it worked pretty well. > I'm sure 99% of the SQL statements were identical. In this case > I used a product called JAM. (it's now called Panther, and is free > on Linux, see www.possl.org. Unfortunately, programming in its > language JPL feels like having your right hand tied behind your > back if you are used to Python.) >=20 > I've also used DB2, Access, Sybase, MySQL etc, and almost all the > time I manage to restrict myself to using standard SQL constructs. That's possible indeed, but only if you restrict yourself to the absolute minimum in terms of data types and functionality. Some examples which almost always need some way of tweaking: * auto-increment or sequencing * blobs and other more esoteric data types like images and Unicode * for MySQL and non-SQL databases: sub-selects, joins, views, transaction= s * count() * select distinct * locking * transaction isolation * database, table and user creation * various limits on data types * syntax for defining data types * names of data types and probably a dozen more. >> The freedom is needed so that you can support >> more than just one backend, e.g. a flat file database is likely >> to behave differently than a full blown SQL Server. >=20 >=20 > Has anyone ever shown any interest in such a thing? There > are a number of Python drivers for accessing flat files, but > none that use the DB API that I heard of. Wouldn't a higher > level of abstraction be more appropriate for a uniform access > to flat files and SQL databases? Yet another plug ;-)... mxODBC can access Excel, CSV (and a few other similar formats) files on Windows. > I can't see a reason to discuss other types of databases than > SQL databases (well, more or less SQL ;) when it concerns the > DB API. There are a lot of constructs such as cursors etc that > don't mean anything in most other types of databases. mxBeeBase is an example of a flat-file database which does have cursors, but where SQL doesn't make too much sense. It should be easy to come up with some similar query dialect, though. Another idea would be to use it as backend for Gadfly. >> Certainly not. If you would want to enforce a standard >> paramstyle then you'd have to add a parser to the modules >> that don't support the "standard" way of writing parameters >> defined by some DB API spec. >=20 > Maybe this is an effort that could be made once, and shared > between drivers? I think someone already write a helper which does this (converts various formats into one); we certainly can't force database module authors to use it, though. >> Maybe for you, but not for the majority. The DB API has a very >> long success story. This is evidence enough for me that the >> approach was the right one. >=20 >=20 > Majority of what? Majority of actual users, or majority of > people who could have been users?=20 Majority of users who have used Python's DB API modules in the past. We would have had many more outcries if people had felt that the DB API is not up to the task. > I'm greatful for the work > that so many people have put into this, but I don't think we > should deny that it could be much more accessible. Certainly not. Improvements are always possible. You do have to know what you want though and I have a feeling that Java people are missing their JDBC in Python. If that's the case, then we have a need for a JDBC style interface in Python -- perhaps on top of the existing DB API interface (which is much more low-level). > I've programmed extensively in SQL since 1990 and in Python > since 1996, but I've still never used any DB API driver beyond > the ODBC driver in the Mark Hammond's Windows extensions. :-( >=20 > This is partly because I've never desperately needed it, but it > has happened a few times that I choose to popen shell scripts > with SQL calls, or that I made SQL queries to text files which > I processed in Python. If the threshold to use DB API comliant > drivers had been lower, I'm pretty sure that's the way I would > have gone. >=20 > How ever we go about things, we can't expect the Python standard > library to include binary versions of most popular databases on > all the platforms Python supports. >=20 > So there will always be a higher threshold to using SQL from > Python than to use Python in general. It would be really great > if an ODBC driver could be included in the standard library, but > I suppose this is something I'll just have to dream about. As I > said, I understand Marc-Andr=E9's position, but I can always dream, > can't I? ;-) ODBC is a *very* complicated beast, not only because the standard was written by Microsoft, but also because drivers and databases support various levels of ODBC which are not necessarily compatible. You wouldn't want to maintain it ;-) I can assure you that it's much more fun programming DB API than ODBC. --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From dustin+pydbsig@spy.net Fri Jun 21 21:36:57 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Fri, 21 Jun 2002 13:36:57 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D136F6D.2060108@lemburg.com> Message-ID: Around 20:24 on Jun 21, 2002, M.-A. Lemburg said: # > How can you simultaneously argue that the DB API was intentionally # > designed ambiguously to allow as many backend systems as possible, and # > state that there's another driver API out there that supports ``pretty # > much all major databases'' that has a consistent interface? # # I don't see your point. # # mxODBC implements DB API 2.0 and extends it with a lot of other # interesting APIs which ODBC provides. All the standardization work is # done (more or less) in the ODBC drivers. This allows mxODBC to provide a # consistent interface to multiple databases. # # I don't see how this is in conflict with saying that an interface like # the Python DB API needs to be flexible to allow for more than one # backend. You're saying that DB API can't be any more standardized because it'd prevent multiple backends from being used, and if I want something more standardized, I'd have to go with another database API that is already standardized and provides access to multiple backends. The existence of even one invalidates the first statement, but java, perl, ruby, etc... each has a database API providing common access across multiple databases. Again, I'm not saying it's worthless, but it does need to be fixed, and it's *certaily* possible to have an abstracted database API that will work the same way across multiple databases without having to modify application code. Fixing it will likely require some tough decisions to be made and will mostly likely place a greater burden on driver developers, but, IMO, that's OK. I believe a few people have mentioned that creating a base framework from which all database implementations should extend, and I think that's an excellent idea. I have no problem doing the abstract implementation of such a framework (at least a good chunk of one) and possibly even a driver implementing it. I had the intention of doing this and proposing it at some point, but I haven't taken the time to start yet. # > I believe that arguing that it's unimportant to keep B consistent # > because you'll probably have to change A anyway is invalid. Personally, # > I've rarely had to change my SQL when going between PostgreSQL and Sybase. # > When I do have to change a query for a specific database, I deal with # > that. My abstraction layer deals with that in such a way that I just have # > to drop the two queries in and it's good. However, this is all java code # > and I have never had to change the way I talk to the DB when switching # > between postgres and sybase. My abstraction layer doesn't have to do # > anything but select a query when they are different. # # That's nice. Why don't you write a wrapper for Python that implements # JDBC on top of all existing DB API interface ? Because the lack of consistency in the API would mean that I would first have to know about all DB API implementations, have the databases to which they connect, and write special code for each individual API implementation, even if the same query were being sent through. In the meantime, I've been using jython and JDBC for my application development, as I work on more than one database and don't want to put forth the effort to learn how to use more than one way to connect to my databases right now. # > To me, that says you can't group fundamentally different things # > under a single API. # # That's Java-thinking. Python works in terms of interfaces and that's # also how the DB API is designed, Java thinking? In that case, why do we need a DB API, why not just make a generic API for everything we could possibly conceive (network, database, print, UI, etc...) and have everything extend from that? But I don't understand how you're trying to sway me with that statement. JDBC is a set of java interfaces all database drivers must implement. This allows end users to know exactly what to expect, and driver developers to know when they're done. Anyway, Java's not the topic here, I've just been using it as evidence that it's possible to have an abstracted driver API that is consistent across multiple databases. # Great. If you can provide patches for all the Python drivers, I'm sure # the authors would love to integrate them ;-) Doing the same work in multiple places is certainly not the best way to get anything done. I think this speaks for the need for a common API from which all driver developers should extend. I also wouldn't want to go around changing the way everything works in a way that I believe makes things better if everyone else disagrees. It doesn't make sense to start making changes until a new API is finalized. # Nothing is ever perfect, only good enough :-) Of course, there are # things in the DB API that could be better, but it's pretty useful in its # current state already, so there's really no need to try to talk it down. Again, I'm not saying it's bad. Here's an example. If you go to http://dbi.x.perl.org/ you see this written at the top of the page: ``The DBI is a database interface module for Perl. It defines a set of methods, variables and conventions that provide a consistent database interface independent of the actual database being used.'' -- Tim Bunce What's wrong with having a similar design goal in python? If your stated design goal is to achieve database independence, then you will start making decisions that will get you there. A db package with extensions, types, etc...and maybe some helper classes for the driver developers would get us there quickly. # > This statement reads as if you don't believe there is a DB API, # > and/or that the python community isn't capable of coming up with one (as # > opposed to what you said, ``multiple different interface[s]''). # # The strategy is different to what you have in mind: the DB API defines # an API for database interfaces, not an interface to databases, like e.g. # the Perl DBI concept. We don't have a driver - manager setup. It's only # drivers. I don't understand why there should be a difference. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From info@mjais.de Fri Jun 21 21:40:29 2002 From: info@mjais.de (Markus Jais) Date: Fri, 21 Jun 2002 22:40:29 +0200 Subject: [DB-SIG] MySQLdb-0.9.2 release candidate 1 In-Reply-To: <1024616743.10975.30.camel@4.0.0.10.in-addr.arpa> References: <1024616743.10975.30.camel@4.0.0.10.in-addr.arpa> Message-ID: <200206212240.30178.info@mjais.de> hello I have a problem compiling it on my Red Hat 7.3 system with python 2.2.1 and mysql 3.23.49 which comes with Red Hat 7.3 I type python setup.py build and I get this error: gcc -shared build/temp.linux-i686-2.2/_mysql.o -L/usr/lib/mysql -L/usr/local/lib/mysql -L/usr/local/mysql/lib/mysql -lmysqlclient_r -lz -o build/lib.linux-i686-2.2/_mysql.so /usr/bin/ld: cannot find -lmysqlclient_r collect2: ld returned 1 exit status the mysql libs are under /usr/lib/mysql but there is no libmysqlclient_r , there is only libmysqlclient (without the "_r") what can I do ? I think I have installed all mysql stuff that was on the Red Hat CD's markus On Friday 21 June 2002 01:45, Andy Dustman wrote: > There's actually quite a bit more in here than I would like in a release > candidate; I seriously considered making this another beta, but my own > testing seems to indicate that it's stable. The release notes are here: > > http://sourceforge.net/project/shownotes.php?release_id=95924 > > Most interesting tidbits: > > * _mysql.connection and .result objects which can be used as new-style > base classes in Python 2.2 or newer > > * Greatly expanded internal documentation (for pydoc) > > * Improved unicode and blob/array support > > * Package name mimics python.org RPM naming convention > > * A sprinkling of bug fixes > > Get it here: > > http://sourceforge.net/project/showfiles.php?group_id=22307&release_id=9592 >4 -- Markus Jais http://www.mjais.de info@mjais.de The road goes ever on and on - Bilbo Baggins From dustin+pydbsig@spy.net Fri Jun 21 21:56:31 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Fri, 21 Jun 2002 13:56:31 -0700 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D137F17.70605@lemburg.com> Message-ID: Around 21:31 on Jun 21, 2002, M.-A. Lemburg said: # * blobs and other more esoteric data types like images and Unicode # * transaction isolation I think these two could be handled by the API, at least. Yeah, some of that stuff is hard, though, especially when dealing with non-standard SQL databases (which I would suggest avoiding in the first place, but that's a different matter). # I think someone already write a helper which does this (converts various # formats into one); we certainly can't force database module authors to # use it, though. You could encourage them to not reproduce existing work, though. As a driver developer, I would want to leverage as much existing work as possible to get my job done, but as an application developer, I would want to start writing DB code without first having to ask the driver how it wants it. # > Majority of what? Majority of actual users, or majority of # > people who could have been users? # # Majority of users who have used Python's DB API modules in the past. We # would have had many more outcries if people had felt that the DB API is # not up to the task. Speaking for myself, I joined this list because I thought it was lacking, but have been lurking because I haven't had the time to help improve it yet. When I noticed other people bringing up some of the same problems I had noticed, I spoke up. I wouldn't assume that just because people are using it that it doesn't need help. # Certainly not. Improvements are always possible. You do have to know # what you want though and I have a feeling that Java people are missing # their JDBC in Python. If that's the case, then we have a need for a JDBC # style interface in Python -- perhaps on top of the existing DB API # interface (which is much more low-level). This is a good point. I had thought about coming up with an API spec that covered some of the things I felt were missing and implementing it on top of another driver to demonstrate. It seems to me that higher level APIs should be preferred for application developers over lower level APIs, but that does not necessarily mean that lower level APIs shouldn't exist. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From gerhard.haering@gmx.de Fri Jun 21 22:03:28 2002 From: gerhard.haering@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Fri, 21 Jun 2002 23:03:28 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: References: <3D136F6D.2060108@lemburg.com> Message-ID: <20020621210328.GA609@lilith.my-fqdn.de> * Dustin Sallings [2002-06-21 13:36 -0700]: > [to MAL] > You're saying that DB API can't be any more standardized because > it'd prevent multiple backends from being used, and if I want something > more standardized, I'd have to go with another database API that is > already standardized and provides access to multiple backends. The > existence of even one invalidates the first statement, but java, perl, > ruby, etc... each has a database API providing common access across > multiple databases. > > Again, I'm not saying it's worthless, but it does need to be > fixed, and it's *certaily* possible to have an abstracted database API > that will work the same way across multiple databases without having to > modify application code. > > Fixing it will likely require some tough decisions to be made and > will mostly likely place a greater burden on driver developers, but, IMO, > that's OK. I believe a few people have mentioned that creating a base > framework from which all database implementations should extend, and I > think that's an excellent idea. I also think that the base framework would be an very good idea. +1 on creating one. Who's joining? > [...] Because the lack of consistency in the API would mean that I would > first have to know about all DB API implementations, have the databases to > which they connect, and write special code for each individual API > implementation, even if the same query were being sent through. It would also be useful to make sure that the same exceptions are thrown in the various backends. The correct exception to throw is sometimes difficult to find out from the DB-API specs. As a module developer _and_ user, I'd like to get away with the various paramstyles and have only one paramstyle standardized. I personally like pyformat best. Alternatively, some wrapper in the base framework to convert from the standardized paramstyle to the one the module is using internally. Also, standardizing connectin parameters looks like a good idea, and I also like the MySQLdb extension def cursor(cursorclass=self.defdefaultcursor) in the Connection class. I've borrowed this for PySQLite and I believe we'll also add it to PyPgSQL. In short: I don't agree with the argument that the implementation freedom for paramstyles et al. buys the developers much. As PyPgSQL 3.0 will be the first release to require Python 2.2 that looks like a good time to add other possibly incompatible changes, like a revised DB-API. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From gerhard.haering@gmx.de Fri Jun 21 22:09:41 2002 From: gerhard.haering@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Fri, 21 Jun 2002 23:09:41 +0200 Subject: [DB-SIG] MySQLdb-0.9.2 release candidate 1 In-Reply-To: <200206212240.30178.info@mjais.de> References: <1024616743.10975.30.camel@4.0.0.10.in-addr.arpa> <200206212240.30178.info@mjais.de> Message-ID: <20020621210941.GB609@lilith.my-fqdn.de> * Markus Jais [2002-06-21 22:40 +0200]: > hello > I have a problem compiling it on my Red Hat 7.3 system with > python 2.2.1 and mysql 3.23.49 which comes with Red Hat 7.3 > > I type > python setup.py build > and I get this error: > > gcc -shared build/temp.linux-i686-2.2/_mysql.o -L/usr/lib/mysql > -L/usr/local/lib/mysql -L/usr/local/mysql/lib/mysql -lmysqlclient_r -lz -o > build/lib.linux-i686-2.2/_mysql.so > /usr/bin/ld: cannot find -lmysqlclient_r > collect2: ld returned 1 exit status > > the mysql libs are under > /usr/lib/mysql > > but there is no libmysqlclient_r , there is only libmysqlclient (without > the "_r") > > what can I do ? Read the setup.py :-) thread_safe_library = YES Change this to NO. > I think I have installed all mysql stuff that was on the Red Hat CD's Maybe the *ead*at MySQL binaries aren't that good if they even don't include the thread-safe libraries. You could compile MySQL yourself or get RPMs at the MySQL site to get the thread-safe libraries. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From abchou@wharton.upenn.edu Fri Jun 21 23:28:56 2002 From: abchou@wharton.upenn.edu (Chou, Abc) Date: Fri, 21 Jun 2002 18:28:56 -0400 Subject: [DB-SIG] importing data from an HTML page to access Message-ID: <8CFDEDD569991D43BC84141B2A93A5C8DE1D8C@stock1.wharton.upenn.edu> hi, we are having trouble with importing data from a webpage onto access. the main problem is trying to enter data into successive fields. we are just beginners, and listed below is what we have so far. we would really appreciate any suggestions on what the next step is to import the next rows of data into the database. here is the code. thanks for any help you can give us. import string import urllib, re import win32com.client engine=win32com.client.Dispatch("DAO.DBEngine.36") db=engine.OpenDatabase(r'z:\Case 3\Case3.mdb') ob = urllib.urlopen('http://opim.wharton.upenn.edu/~opim101/spring02/Plant1.html') #rs = db.OpenRecordset("TotalPlantDemand") bs = ob.readlines() a1 = 0 ind = 3 #for i in range(rs.Fields.Count): for s in bs: rs = db.OpenRecordset("TotalPlantDemand") str = bs[3:] b1 = string.split(str[0], ',') b2 = b1[0:] l1 = b2[0] #l2 = string.split(l1[4], ' ') orderid = l1[4:9] for s in bs: db.Execute("insert into TotalPlantDemand values("+(orderid)+",'+#(b2[1])#+',"+(b2[2])+","+(b2[3])+","+(b2[4])+")") #rs.MoveNext() #print orderid #print b2[1:] a1+=1 From john@nmt.edu Sat Jun 22 00:11:04 2002 From: john@nmt.edu (John W. Shipman) Date: Fri, 21 Jun 2002 17:11:04 -0600 (MDT) Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <5.1.0.14.0.20020621113010.024874f0@www.thinkware.se> Message-ID: On Fri, 21 Jun 2002, Magnus Lycka wrote: +-- | I have a dozen Python books in my book shelf. The only ones | that cover the DB API is Hammond/Robinsons Win32 book and | Holden's new Python Web Programming. I think we can agree that | python database programming isn't as visible as it could be. I | hope this will change though. +-- Have a look at this new book: Deitel, Harvey; Paul Deitel; Jonathan Liperi; and Ben Wiedermann. Python How To Program [sic]. Prentice-Hall, 2002, ISBN 0-13-092361-3. I think it does a reasonable job of covering the DBAPI along with a cursory introduction to the relational model and SQL. Full disclosure: although I had nothing to do with the writing of this book, and have no financial interest in its success, I was paid an honorarium for reviewing some of the chapters. Cheers, John Shipman (john@nmt.edu), Applications Specialist, NM Tech Computer Center, Speare 128, Socorro, NM 87801, (505) 835-5950, http://www.nmt.edu/~john ``Let's go outside and commiserate with nature.'' --Dave Farber From andy@dustman.net Sat Jun 22 01:28:38 2002 From: andy@dustman.net (Andy Dustman) Date: 21 Jun 2002 20:28:38 -0400 Subject: [DB-SIG] MySQLdb-0.9.2 release candidate 1 In-Reply-To: <20020621210941.GB609@lilith.my-fqdn.de> References: <1024616743.10975.30.camel@4.0.0.10.in-addr.arpa> <200206212240.30178.info@mjais.de> <20020621210941.GB609@lilith.my-fqdn.de> Message-ID: <1024705718.2387.6.camel@4.0.0.10.in-addr.arpa> On Fri, 2002-06-21 at 17:09, Gerhard H=E4ring wrote: > * Markus Jais [2002-06-21 22:40 +0200]: > > hello > > I have a problem compiling it on my Red Hat 7.3 system with > > python 2.2.1 and mysql 3.23.49 which comes with Red Hat 7.3 ... > > but there is no libmysqlclient_r , there is only libmysqlclient (witho= ut > > the "_r") > >=20 > > what can I do ? >=20 > Read the setup.py :-) >=20 > thread_safe_library =3D YES >=20 > Change this to NO. Indeed, this is in README as well. =20 > > I think I have installed all mysql stuff that was on the Red Hat CD's >=20 > Maybe the *ead*at MySQL binaries aren't that good if they even don't > include the thread-safe libraries. You could compile MySQL yourself or > get RPMs at the MySQL site to get the thread-safe libraries. I personally always use the mysql.com RPMs; they seem to always come with the thread-safe libraries, and MySQL-shared has the shared libraries. My build environment is Red Hat 7.3 i386 with the mysql.com RPMs and gcc-2.96-x (stock Red Hat). I think the mysql.com RPMs are compiled with gcc3 nowadays, so I might switch to that. But I'm adverse to building RPMs for test releases. For some reason, the mysql.com RPMs do not come with libmysqld, which you can use instead of libmysqlclient(_r) for the embedded server, so I haven't really taken the time to implement this (apparently it's trivial, but without the library, I can't test things).=20 --=20 Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From andy@dustman.net Sat Jun 22 02:01:20 2002 From: andy@dustman.net (Andy Dustman) Date: 21 Jun 2002 21:01:20 -0400 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D137F17.70605@lemburg.com> References: <5.1.0.14.0.20020621113010.024874f0@www.thinkware.se> <3D137F17.70605@lemburg.com> Message-ID: <1024707680.2387.39.camel@4.0.0.10.in-addr.arpa> On Fri, 2002-06-21 at 15:31, M.-A. Lemburg wrote: > Some examples which almost always need some way of tweaking: > > * auto-increment or sequencing > * blobs and other more esoteric data types like images and Unicode > * for MySQL and non-SQL databases: sub-selects, joins, views, transactions > * count() > * select distinct > * locking > * transaction isolation > * database, table and user creation > * various limits on data types > * syntax for defining data types > * names of data types > > and probably a dozen more. I think this highlights that there are two separate portability issues. 1) Ability to execute queries on the database and return results 2) The queries themselves DB-API does a good job, IMHO, on point 1, once you get a connection object. If we were doing another version, I'd standardize connect by ditching connection *strings* for connection *parameters* (host, user, passwd are pretty universal) and keyword arguments for anything else. DB-API doesn't do much for point 2, nor was it ever intended to. It doesn't even require that SQL be passed to .execute. That, perhaps, should be a job for the SQL-API, which doesn't exist, but could be an additional layer on top of DB-API. Indeed, this could be a fairly standard wrapper/proxy class for a connection object which is extended as needed with mixins for various implementations (DB-API modules) which actually constructs SQL statements. I'm presently working on something along these lines and might have something to show for it by OsCon 2002. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From magnus@thinkware.se Sat Jun 22 19:42:54 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Sat, 22 Jun 2002 20:42:54 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: References: <3D136F6D.2060108@lemburg.com> Message-ID: <5.1.0.14.0.20020622201541.026f8cf8@www.thinkware.se> At 13:36 2002-06-21 -0700, Dustin Sallings wrote: >java, perl, >ruby, etc... each has a database API providing common access across >multiple databases. I'm curious: Can anyone share some experiences concerning Perl::DBI, JDBC etc. Do they limit the programmer, so that vendor specific SQL extensions can't be used? Are they very complex? Do they have a significant negative impact on performance compared to native drivers? I certainly think it would be good to have a uniform way to speak to databases. And I would love to be able to use it with Python. :-) Might JDBC possibly be the way to go, if ODBC is such a nightmare? It might be clever not to invent the wheel once more. At 20:32 2002-06-21 +0200, M.-A. Lemburg wrote: > In reality you'll rarely have to switch database backends for > applications and if you do, you'll make sure that the effort > needed to do this will be minimal (or well-payed ;-). But we might have the same application running at different locations, for different customers, who don't want a different RDBMS for every applications they have bought. Ok, today few will buy anything else than MS SQL Server, Oracle or DB2, but they might have Informix, Sybase etc since years back, and might not want to change right now... Also, In my consulting, I tend to emphasize the importance of vendor independence. After all, I make a point of programming in a very high level language which is very platform independent and also free. Having the lowest possible cost in switching for instance databases is a sales argument for me. I realize that there are a number of other costs in such an effort--data conversion, DBA training etc, but I still find it valuable to make the switch as simple as possible from a programming point of view. I recently worked for a large government agency that switched from Oracle to DB2 half way into a project, since the licence fees differed by a magnitude! This was a large system with tens of thousands of users, and the amount of money saved here certainly paid for a lot of programming efforts, but most customers are much smaller than this. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From lennie.jarratt@bigidea.com Sun Jun 23 06:17:54 2002 From: lennie.jarratt@bigidea.com (Lennie Jarratt) Date: Sun, 23 Jun 2002 00:17:54 -0500 Subject: [DB-SIG] informixdb-1.3 Install help Message-ID: <3D155A02.4090307@bigidea.com> I am trying to install informixdb-1.3 with Python 2.1. When I run make (using gmake) I get the following error: make[1]: Entering directory `/disk2/zope/informixdb-1.3/ext' make[1]: Circular _informixdb.c <- _informixdb.c dependency dropped. gcc -shared ./_informixdb.o ./dbi.o -L/export/home/informix/informix/lib -L/ex port/home/informix/informix/lib/esql -lifsql -lifasf -lifgen -lifos -lifgls -lns l -lsocket -laio -lm -ldl -lelf /export/home/informix/informix/lib/esql/checkapi.o -lifglx -o ./_informixdb.so ld: fatal: file /export/home/informix/informix/lib/esql/libifsql.so: wrong ELF class: ELFCLASS64 ld: fatal: file /export/home/informix/informix/lib/libifasf.so: wrong ELF class: ELFCLASS64 ld: fatal: file /export/home/informix/informix/lib/esql/libifgen.so: wrong ELF class: ELFCLASS64 ld: fatal: file /export/home/informix/informix/lib/esql/libifos.so: wrong ELF class: ELFCLASS64 ld: fatal: file /export/home/informix/informix/lib/esql/libifgls.so: wrong ELF class: ELFCLASS64 ld: fatal: file /export/home/informix/informix/lib/esql/checkapi.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to ./_informixdb.so collect2: ld returned 1 exit status make[1]: *** [_informixdb.so] Error 1 make[1]: Leaving directory `/disk2/zope/informixdb-1.3/ext' make: *** [sharedmods] Error 2 Is this because I am using the 64 bit Informix Client or is there another reason? Thanks. Lennie From mal@lemburg.com Mon Jun 24 09:23:03 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jun 2002 10:23:03 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: <5.1.0.14.0.20020621113010.024874f0@www.thinkware.se> <3D137F17.70605@lemburg.com> <1024707680.2387.39.camel@4.0.0.10.in-addr.arpa> Message-ID: <3D16D6E7.7090506@lemburg.com> Andy Dustman wrote: > On Fri, 2002-06-21 at 15:31, M.-A. Lemburg wrote: > >>Some examples which almost always need some way of tweaking: >> >>* auto-increment or sequencing >>* blobs and other more esoteric data types like images and Unicode >>* for MySQL and non-SQL databases: sub-selects, joins, views, transactions >>* count() >>* select distinct >>* locking >>* transaction isolation >>* database, table and user creation >>* various limits on data types >>* syntax for defining data types >>* names of data types >> >>and probably a dozen more. > > > I think this highlights that there are two separate portability issues. > > 1) Ability to execute queries on the database and return results > > 2) The queries themselves > > DB-API does a good job, IMHO, on point 1, once you get a connection > object. If we were doing another version, I'd standardize connect by > ditching connection *strings* for connection *parameters* (host, user, > passwd are pretty universal) and keyword arguments for anything else. > > DB-API doesn't do much for point 2, nor was it ever intended to. It > doesn't even require that SQL be passed to .execute. That, perhaps, > should be a job for the SQL-API, which doesn't exist, but could be an > additional layer on top of DB-API. Indeed, this could be a fairly > standard wrapper/proxy class for a connection object which is extended > as needed with mixins for various implementations (DB-API modules) which > actually constructs SQL statements. Hmm, it's not only about generating SQL for queries, it's also about semantics and different data type implementations. I have such an abstract interface for the eGenix Application Server which basically wraps up connections and cursors and adds higher level methods to them like e.g. .count(condition), .get(id), .add(id, record), .remove(id), .update(id, record). Tables add another layer on top of these, so that the programming interface becomes an application (and table) specific one. Tables are then subsummed in Database objects which provide cross-table interfacing. The programmer doesn't see a single line of SQL at the highest level. Database integrity is maintained by the different layers and differences in syntax and semantics are handled there as well. Works great :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From mal@lemburg.com Mon Jun 24 09:28:12 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 24 Jun 2002 10:28:12 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 References: <3D136F6D.2060108@lemburg.com> <5.1.0.14.0.20020622201541.026f8cf8@www.thinkware.se> Message-ID: <3D16D81C.7070504@lemburg.com> Magnus Lycka wrote: > At 13:36 2002-06-21 -0700, Dustin Sallings wrote: > >> java, perl, >> ruby, etc... each has a database API providing common access across >> multiple databases. > > > I'm curious: Can anyone share some experiences concerning > Perl::DBI, JDBC etc. Do they limit the programmer, so that > vendor specific SQL extensions can't be used? > > Are they very complex? > > Do they have a significant negative impact on performance > compared to native drivers? > > I certainly think it would be good to have a uniform > way to speak to databases. And I would love to be able > to use it with Python. :-) > > Might JDBC possibly be the way to go, if ODBC is such > a nightmare? It might be clever not to invent the wheel > once more. Right. JDBC does a pretty job at providing a logical interface to databases. It uses the concept driver - interface, but that can easily be had in Python since our drivers are the DB API modules. We would need some more standard data types for this, though, e.g. a fixed decimal point type. > At 20:32 2002-06-21 +0200, M.-A. Lemburg wrote: > > In reality you'll rarely have to switch database backends for > > applications and if you do, you'll make sure that the effort > > needed to do this will be minimal (or well-payed ;-). > > But we might have the same application running at different > locations, for different customers, who don't want a different > RDBMS for every applications they have bought. Ok, today few will > buy anything else than MS SQL Server, Oracle or DB2, but they > might have Informix, Sybase etc since years back, and might > not want to change right now... > > Also, In my consulting, I tend to emphasize the importance of vendor > independence. After all, I make a point of programming in a very > high level language which is very platform independent and also > free. Having the lowest possible cost in switching for instance > databases is a sales argument for me. I realize that there are a > number of other costs in such an effort--data conversion, DBA > training etc, but I still find it valuable to make the switch as > simple as possible from a programming point of view. > > I recently worked for a large government agency that switched from > Oracle to DB2 half way into a project, since the licence fees differed > by a magnitude! This was a large system with tens of thousands of > users, and the amount of money saved here certainly paid for a lot of > programming efforts, but most customers are much smaller than this. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/ From Anthony Baxter Mon Jun 24 09:42:32 2002 From: Anthony Baxter (Anthony Baxter) Date: Mon, 24 Jun 2002 18:42:32 +1000 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D137F17.70605@lemburg.com> Message-ID: <200206240842.g5O8gWs27177@localhost.localdomain> >>> "M.-A. Lemburg" wrote > >> Maybe for you, but not for the majority. The DB API has a very > >> long success story. This is evidence enough for me that the > >> approach was the right one. > > = > > = > > Majority of what? Majority of actual users, or majority of > > people who could have been users? = > = > Majority of users who have used Python's DB API modules > in the past. We would have had many more outcries if people > had felt that the DB API is not up to the task. Well, speaking as someone who's been using python database interfaces a long long time (I wrote the original mSQL interface back in the = dark dark ages of 1996 or so), I'd say I'm not particularly happy with the current state of the art. = I've not bothered making a song and dance about it because I don't = have the time or energy to put into making it better at the moment, but I know I'd prefer a standard higher level and more standard interface= =2E = Anthony -- = Anthony Baxter = It's never too late to have a happy childhood. From daniel.dittmar@sap.com Mon Jun 24 11:37:18 2002 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 24 Jun 2002 12:37:18 +0200 Subject: Higher level constructs (was: [DB-SIG] Experiences with DB-API2.0 ) Message-ID: Perhaps it would be a good idea to list the high level constructs: fetchrow_hashref (from Perl): returning a mapping from column names to values instead of a tuple implementable through proxy classes: YES my take: how about a callable object which acts like a filter for every row. This would allow a lot of other neat stuff like creating a Python object from a row or fetching detail information for a master row scrollable cursors (ODBC, JDBC): implementable through proxy classes: NO, unless you don't mind having the whole result set in memory updatable cursors (ODBC, JDBC): implementable through proxy classes: NO meta data (ODBC, JDBC): implementable on top of DB API: YES, but the code would be database specific my take: instead of copying either ODBC or JDBC, I would now prefer something like http://dbdoc.sourceforge.net/ (see: simple Python API for inspecting DB schemas), cursors are just too clumsy for this kind of data runtime checks for DB API conformance: implementable through proxy classes: YES my take: as a driver author, I really resent - disabling features of the database - writing complex checks for stuff that won't do any harm (example from JDBC: parsing SQL commands so that no SELECT gets through an executeUpdate) I could imagine that there will exist multiple check proxies to go with the most common sets of porting targets, say one checker for PostgreSQL + MySQL, one for Oracle + DB2 + SAP DB, etc... common data type handling: DATE/TIME, BLOBs, fixed decimal common SQL lexer: - parameter style - SQL identifier (quote, case sensitivity) - literals common SQL syntax: No, JDBC or DBI don't provide this either. -- Daniel Dittmar SAP DB, SAP Labs Berlin daniel.dittmar@sap.com http://www.sapdb.org/ From magnus@thinkware.se Mon Jun 24 14:34:46 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Mon, 24 Jun 2002 15:34:46 +0200 Subject: [DB-SIG] Experiences with DB-API2.0 In-Reply-To: <3D16D81C.7070504@lemburg.com> References: <3D136F6D.2060108@lemburg.com> <5.1.0.14.0.20020622201541.026f8cf8@www.thinkware.se> Message-ID: <5.1.0.14.0.20020624121051.00bc6170@www.thinkware.se> At 10:28 2002-06-24 +0200, M.-A. Lemburg wrote: >We would need some more standard data types for this, >though, e.g. a fixed decimal point type. Together with a reasonable date/time type (or class) I think this would be a very good addition to the Python standard library. Those batteries should certainly be included... --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From andy@dustman.net Mon Jun 24 14:48:40 2002 From: andy@dustman.net (Andy Dustman) Date: 24 Jun 2002 09:48:40 -0400 Subject: Higher level constructs (was: [DB-SIG] Experiences with DB-API2.0 ) In-Reply-To: References: Message-ID: <1024926520.1920.15.camel@4.0.0.10.in-addr.arpa> On Mon, 2002-06-24 at 06:37, Dittmar, Daniel wrote: > Perhaps it would be a good idea to list the high level constructs: > > fetchrow_hashref (from Perl): > returning a mapping from column names to > values instead of a tuple > implementable through proxy classes: YES > my take: how about a callable object which acts like > a filter for every row. This would allow a lot of > other neat stuff like creating a Python object > from a row or fetching detail information for a > master row My approach on MySQLdb was to implement different row formats with different Cursor classes. However, this is an interesting idea that is totally trivial to implement, at least with my implementation... > scrollable cursors (ODBC, JDBC): > implementable through proxy classes: NO, unless you > don't mind having the whole result set in memory Some MySQLdb Cursors can scroll (those using CursorStoreResultMixIn), for this exact reason. > updatable cursors (ODBC, JDBC): > implementable through proxy classes: NO Not sure what this entails... > meta data (ODBC, JDBC): > implementable on top of DB API: YES, but > the code would be database specific > my take: instead of copying either > ODBC or JDBC, I would now prefer something > like http://dbdoc.sourceforge.net/ (see: > simple Python API for inspecting DB schemas), > cursors are just too clumsy for this kind of data The description attribute gives most of this data, but of course you have to execute a query to get it (SELECT *) and deal with a result set. -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From paul@boddie.net Mon Jun 24 14:54:21 2002 From: paul@boddie.net (paul@boddie.net) Date: 24 Jun 2002 13:54:21 -0000 Subject: [DB-SIG] Experiences with DB-API2.0 Message-ID: <20020624135421.8842.qmail@www1.nameplanet.com> Andy Dustman wrote: > >On Fri, 2002-06-21 at 15:31, M.-A. Lemburg wrote: >> Some examples which almost always need some way of tweaking: >> >> * auto-increment or sequencing Compare MySQL and PostgreSQL for example. To a point, though, I can imagine that it is possible to implement a procedure or an extension in MySQL to give PostgreSQL-style sequences, and it might be possible to implement something in PostgreSQL to support self-incrementing columns, although I'd want to stay well away from either activity. Even when considering portability between databases that favour sequences (Oracle, PostgreSQL) the syntax used to access sequences differs. I suppose that the best approach, where possible, is to modify the database environment as much as possible to suit the Python applications. If that means some stored procedure implementation, then I would consider that the best solution, as opposed to writing lots of Python-based abstraction code. >> * blobs and other more esoteric data types like images and Unicode JDBC does at least provide some support for this. >> * for MySQL and non-SQL databases: sub-selects, joins, views, transactions See below for pertinent remarks from Mr Dustman. >> * count() >> * select distinct I suppose different behaviour can be experienced here, but also see below. >> * locking >> * transaction isolation >> * database, table and user creation >> * various limits on data types >> * syntax for defining data types >> * names of data types So-called administrative functions are arguably somewhat easier to factor out of most applications, although the point below also addresses this somewhat. Certainly, the average SELECT, INSERT or UPDATE isn't going to get into such details, and where type issues arise, surely JDBC has something to teach us. >> and probably a dozen more. > >I think this highlights that there are two separate portability issues. > >1) Ability to execute queries on the database and return results > >2) The queries themselves This is exactly the point I was referring to. Even JDBC doesn't do too much about (2) despite enforcing certain standard syntax for things like stored procedure invocation. >DB-API does a good job, IMHO, on point 1, once you get a connection >object. If we were doing another version, I'd standardize connect by >ditching connection *strings* for connection *parameters* (host, user, >passwd are pretty universal) and keyword arguments for anything else. Arguably, everything should be a keyword argument. People keep going on about "explicit being better than implicit", so let's enforce that. As for the paramstyle, I would suggest standardising on one style just like JDBC. Some people might miss their favourite style, but the benefits of not having to encode an extra abstraction layer over every statement invocation are just too great. Besides, I'm tempted to think that the use of %s as a paramstyle confuses beginners - they might start to think of parameters as being equivalent to string substitutions, which they are not. >DB-API doesn't do much for point 2, nor was it ever intended to. It >doesn't even require that SQL be passed to .execute. That, perhaps, >should be a job for the SQL-API, which doesn't exist, but could be an >additional layer on top of DB-API. Indeed, this could be a fairly >standard wrapper/proxy class for a connection object which is extended >as needed with mixins for various implementations (DB-API modules) which >actually constructs SQL statements. This is much harder than doing the relatively minor improvements described above, and I would argue that if someone really wants their queries to work everywhere, then they should pay special attention to that themselves (configuring their database systems as much as possible, as stated above). However, this view should *not* obstruct the other work from going ahead, especially since a number of people have expressed their discontent with the current situation. Paul From dustin+pydbsig@spy.net Mon Jun 24 20:42:53 2002 From: dustin+pydbsig@spy.net (Dustin Sallings) Date: Mon, 24 Jun 2002 12:42:53 -0700 Subject: Higher level constructs (was: [DB-SIG] Experiences with DB-API2.0 ) In-Reply-To: Message-ID: Around 12:37 on Jun 24, 2002, Dittmar, Daniel said: # - writing complex checks for stuff that # won't do any harm (example from JDBC: # parsing SQL commands so that no SELECT # gets through an executeUpdate) I agree with most of this here, however on this point, I think it's somewhat important to not think of selects in executeUpdate as harmless. Conversely, as well, if a result set is expected and an update makes its way in, that should be an error. executeUpdate returns an integer telling you how many rows were affected on a delete, insert, or update. executeQuery returns a ResultSet. If the query you issue is not going to provide the correct type of results for the expected call, it should raise an exception. Now, it doesn't necessarily need to parse the query to do this, but some drivers may need to do it that way. -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings | Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L_______________________ I hope the answer won't upset her. ____________ From rtheiss@yahoo.com Wed Jun 26 16:37:37 2002 From: rtheiss@yahoo.com (Robert Theiss) Date: Wed, 26 Jun 2002 08:37:37 -0700 (PDT) Subject: [DB-SIG] General DB Error Handling In-Reply-To: Message-ID: <20020626153738.92716.qmail@web10403.mail.yahoo.com> All, I am writing a python script to connect to an informix database using informixdb.py. I am new to python and object oriented programmign in general, but I have good experience using embedded SQL and C . What I would like to do is trap any error returned from the database, so I can exit the program gracefully. A sample output is shown below, when I intentionally generate an SQL error. [bobt@monza:/service/bobt] > python InfTest.py WARNING: Python C API version mismatch for module _informixdb: This Python has API version 1010, module _informixdb has version 1007. WARNING: Python C API version mismatch for module dbi: This Python has API version 1010, module dbi has version 1007. 20020626 Traceback (most recent call last): File "InfTest.py", line 69, in ? db.execute(SqlSelectStatement) File "/opt/python/lib/python2.1/site-packages/informixdb.py", line 73, in execute return apply(self._cursor.execute, args) InformixdbError: Error -522 performing PREPARE: Table (part) not selected in query. [bobt@monza:/service/bobt] > The python code that generated this output is shown below: LocNbr = 96 SqlSelectStatement = """ select inv_audit.loc_nbr, extend(inv_audit.txn_datet, year to day), part.part_brand, part.part_nbr, part.part_desc, part.dealer_cost, inv_audit.avg_cost, inv_audit.qty_txn, inv_audit.user_id_created_by, inv_audit.inv_audit_info, inv_audit.txn_code, inv_audit.part_id from inv_audit where inv_audit.txn_type = 'RC' and inv_audit.txn_code = 'RE' and inv_audit.loc_nbr = %i and inv_audit.part_id = part.part_id; """ % LocNbr db.execute('set isolation dirty read;') # db.execute(SqlSelectStatement) try: returncode = apply(db.execute(SqlSelectStatement), args) except: print "return code is %s : " % args I'm sure this is basic python, but I've been banging my head against this wall for two days. This is simply my latest attempt. What I am looking for is a way to trap/report the informix -522 error that is shown above when the python module aborted. Any help is appreciated. Regards, Bob Theiss Programmer/Analyst __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From tjenkins@devis.com Wed Jun 26 16:38:15 2002 From: tjenkins@devis.com (Tom Jenkins) Date: 26 Jun 2002 11:38:15 -0400 Subject: [DB-SIG] General DB Error Handling In-Reply-To: <20020626153738.92716.qmail@web10403.mail.yahoo.com> References: <20020626153738.92716.qmail@web10403.mail.yahoo.com> Message-ID: <1025105895.649.8.camel@asimov> On Wed, 2002-06-26 at 11:37, Robert Theiss wrote: > > [bobt@monza:/service/bobt] > python InfTest.py > WARNING: Python C API version mismatch for module > _informixdb: > This Python has API version 1010, module _informixdb > has version 1007. > WARNING: Python C API version mismatch for module dbi: > This Python has API version 1010, module dbi has > version 1007. > 20020626 > Traceback (most recent call last): > File "InfTest.py", line 69, in ? > db.execute(SqlSelectStatement) > File > "/opt/python/lib/python2.1/site-packages/informixdb.py", > line 73, in execute > return apply(self._cursor.execute, args) > InformixdbError: Error -522 performing PREPARE: Table > (part) not selected in query. > [bobt@monza:/service/bobt] > it looks like your informixdb.py catching the exception, dumping a stack trace and never propagating the exception back to the app. that's not good. take a look at informixdb.py around line 73 and see > > The python code that generated this output is shown > below: > > LocNbr = 96 > SqlSelectStatement = """ > select inv_audit.loc_nbr, > extend(inv_audit.txn_datet, year to day), > part.part_brand, part.part_nbr, > part.part_desc, > part.dealer_cost, inv_audit.avg_cost, > > inv_audit.qty_txn, > inv_audit.user_id_created_by, > inv_audit.inv_audit_info, > inv_audit.txn_code, inv_audit.part_id > from > inv_audit > where > inv_audit.txn_type = 'RC' and > inv_audit.txn_code = 'RE' and > inv_audit.loc_nbr = %i and > inv_audit.part_id = part.part_id; > """ % LocNbr > db.execute('set isolation dirty read;') > # db.execute(SqlSelectStatement) > try: > returncode = apply(db.execute(SqlSelectStatement), > args) > except: > print "return code is %s : " % args > > I'm sure this is basic python, but I've been banging > my head against this wall for two days. This is > simply my latest attempt. > What I am looking for is a way to trap/report the > informix -522 error that is shown above when the > python module aborted. > > Any help is appreciated. > > Regards, > > Bob Theiss > Programmer/Analyst > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Tom Jenkins Development InfoStructure http://www.devis.com From andy@dustman.net Wed Jun 26 18:38:00 2002 From: andy@dustman.net (Andy Dustman) Date: 26 Jun 2002 13:38:00 -0400 Subject: [DB-SIG] General DB Error Handling In-Reply-To: <20020626153738.92716.qmail@web10403.mail.yahoo.com> References: <20020626153738.92716.qmail@web10403.mail.yahoo.com> Message-ID: <1025113080.2197.14.camel@4.0.0.10.in-addr.arpa> On Wed, 2002-06-26 at 11:37, Robert Theiss wrote: > What I would like to do is trap any error returned > from the database, so I can exit the program > gracefully. A sample output is shown below, when I > intentionally generate an SQL error. Problem #1: Your module is compiled against the wrong version of Python. It looks like it's compiled for 1.5.2 but you are using a 2.x version. > InformixdbError: Error -522 performing PREPARE: Table > (part) not selected in query. > [bobt@monza:/service/bobt] > > > The python code that generated this output is shown > below: ... > try: > returncode = apply(db.execute(SqlSelectStatement), > args) > except: > print "return code is %s : " % args You want: c = db.cursor() try: c.execute(SqlSelectStatement, args) # return value undefined rows = c.fetchall() except InformixdbError, e: print "return code is %s : " % e -- Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all what I yam." -- Popeye From matt@zope.com Wed Jun 26 18:42:54 2002 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 26 Jun 2002 13:42:54 -0400 Subject: [DB-SIG] General DB Error Handling References: <20020626153738.92716.qmail@web10403.mail.yahoo.com> Message-ID: <3D19FD1E.9020402@zope.com> Robert Theiss wrote: >All, > >I am writing a python script to connect to an informix >database using informixdb.py. I am new to python and >object oriented programmign in general, but I have >good experience using embedded SQL and C . > >What I would like to do is trap any error returned >from the database, so I can exit the program >gracefully. A sample output is shown below, when I >intentionally generate an SQL error. > >[bobt@monza:/service/bobt] > python InfTest.py >WARNING: Python C API version mismatch for module >_informixdb: > This Python has API version 1010, module _informixdb >has version 1007. >WARNING: Python C API version mismatch for module dbi: > This Python has API version 1010, module dbi has >version 1007. >20020626 > > Uh, I'd recompile your modules first! Looks like you're using modules built with Python 1.5.2 with Python 2.1. -- Matt Kromer Zope Corporation http://www.zope.com/