From akuchlin@cnri.reston.va.us Wed Dec 2 14:52:07 1998 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Wed, 2 Dec 1998 09:52:07 -0500 (EST) Subject: [DB-SIG] DB topic guide moves to python.org Message-ID: <13925.21045.477700.406590@amarok.cnri.reston.va.us> I've moved the draft database topic guide to: http://www.python.org/topics/database/ I'd like to make one more pass over it, fill in a few blanks, and then go live with it. * Added a list of database books, along with links to amazon.com. More book suggestions would be really helpful; if you've found a really good book on something DB-related (programming, SQL, design issues, data warehouseing, whatever), please let me know. * Adding more Web links to the DB Resources page would also be nice. I'd rather point to good meta-resources than attempt to be a comprehensive resource on its own; for example, the XML topic guide points to sites like schema.net and xmlsoftware.com and doesn't try to duplicate what those sites are doing. So, are there any similar things for databases? * Need to put Aqueduct somewhere... -- A.M. Kuchling http://starship.skyport.net/crew/amk/ Consumers are like roaches -- you spray them and they get immune after a while. -- David Lubars From greene@info.combichem.com Wed Dec 2 17:42:02 1998 From: greene@info.combichem.com (Jonathan Greene) Date: Wed, 02 Dec 1998 09:42:02 -0800 Subject: [DB-SIG] persistent_id and persistent_load Message-ID: <36657BEA.F75DD0C5@info.combichem.com> These two functions are referred to in the Pickle manual page, but there is not nearly enough information for one to know how to define and use them. I've searched the web site and found no other explanation. Can anyone help? From gstein@lyra.org Wed Dec 2 22:21:21 1998 From: gstein@lyra.org (Greg Stein) Date: Wed, 02 Dec 1998 14:21:21 -0800 Subject: [DB-SIG] persistent_id and persistent_load References: <36657BEA.F75DD0C5@info.combichem.com> Message-ID: <3665BD61.5A56E188@lyra.org> Jonathan Greene wrote: > > These two functions are referred to in the Pickle manual page, but there > is not nearly enough information for one to know how to define and use > them. I've searched the web site and found no other explanation. Can > anyone help? You may want to try on the main list for Pickle questions, rather than on the DB list. I'm not familiar with those two functions, myself. Cheers, -g -- Greg Stein, http://www.lyra.org/ From richard.jones@fulcrum.com.au Thu Dec 3 23:17:11 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Fri, 04 Dec 1998 10:17:11 +1100 Subject: [DB-SIG] Re: oracle db module status In-Reply-To: Message from Aaron_Watters@my-dejanews.com of 1998-Dec-3 15:41:32, <746bfc$2as$1@nnrp1.dejanews.com> Message-ID: <199812032317.KAA08786@icarus.fulcrum.com.au> [cross-posted to DB-SIG, in case someone there cares. I don't subscribe to DB-SIG though, so please CC me any relevant followups] [Aaron_Watters@my-dejanews.com] > richard.jones@fulcrum.com.au wrote: > > I need an interface to Oracle 8, and am finding that most of the oracle > > modules out there (except the Digicool one, but I don't have the option of > > paying for it) are a little out of date with respect to Oracle 8. > > I've used the oracledb module (the freebie) from digicool > with oracle 8, and after the horrible fight to get it linked > it seemed to work without a problem. I also know someone > who is using Anthony Baxter's version and it seems to work > good for him. Well, to expand a little on the post I made... I have Anthony Baxter's oracledb module linked fine with 8.0.5 now. I patched the Makefile to include ${ORACLE_HOME}/rdbms/lib/env_rdbms.mk and then linked with ${TTLIBS}. My problem was that my test select wasn't working properly. After investigating further, I find that a "select * from tab" only returns a row at a time when fetchall()'ed, but a regular table that I make will return all rows on a fetchall(). This is all a bit dodgy, and may result in the killing of Python from the project I'm working on. Now for the icky bit... looking in the 8.0.4 documentation for OCI, I find that all the functions used in oracledb are now deprecated. *sigh* > Conceivably (dunno) it should be possible to > use M.A.Lemburg's mxODBC or (on win32) Bill Tutt's odbc module > or, if you diverge from Greg Stein's dbapi, Sam Rushing's > more direct odbc binding too on win32. Dunno if this helps. > It's all very confusing. ODBC isn't an option, unfortunately. > The problem with diversity is it's so diverse, when all > you wanna do is get the job done! I think I posted a makefile > for oracle8/oracledbmodule to the dbsig many months ago. Well, here's the snippet that works for me: this is the last few lines of the Makefile... include ${ORACLE_HOME}/rdbms/lib/env_rdbms.mk oradbmodule.o: $(srcdir)/oradbmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -I. -I. -c $(srcdir)/oradbmodule.c dbi.o: $(srcdir)/dbi.c; $(CC) $(CCSHARED) $(CFLAGS) -I. -I. -c $(srcdir)/dbi.c oracledbmodule$(SO): oradbmodule.o dbi.o; $(LDSHARED) oradbmodule.o dbi.o -L$ {ORACLE_HOME}/lib ${TTLIBS} -lsocket -lgen -ldl -lc -laio -lm -o oracledbmodule$ (SO) (Note that the oradbmodule.o, dbi.o and oracledbmodule$(SO) lines should be 1 line - but my mail program might break them) Richard -- Richard Jones, developer for the Fulcrum Consulting Group. (03) 9621 2100 http://www.fulcrum.com.au/ http://alumni.dgs.monash.edu.au/~richard/ From ron@graburn.com Fri Dec 4 02:37:00 1998 From: ron@graburn.com (Ronald Hiller) Date: Thu, 03 Dec 1998 21:37:00 -0500 Subject: [DB-SIG] Re: oracle db module status Message-ID: <199812040237.VAA14461@shell.monmouth.com> I had the same experience as you in that fetchmany() returns a single row from a large table. It appears that there is a limit on the number of things returned by the fetchmany() call (it is set to 1000 in Anthony Baxter's version). This still doesn't explain all of the behavior I see, but it helps! Anyways, one solution is: def myfetchmany(cursor): res = [] while 1: r = cursor.fetchone() if not r: break res.append(r) return res A look back at the Digicool freebie module shows it always fetches one row at a time so this will be no worse. I had some problems with the Digicool freebie module with core dumps and infinite loops (always in the cleanup when Python was cleaning up to exit). Ron ========================================================== Ronald Hiller Graburn Technology, Inc. Phone: (732) 845-3999 Suite 250 FAX: (732) 446-6835 716 Newman Springs Road email: ron@graburn.com Lincroft, NJ 07738 ========================================================== >[cross-posted to DB-SIG, in case someone there cares. I don't subscribe to >DB-SIG though, so please CC me any relevant followups] > >[Aaron_Watters@my-dejanews.com] >> richard.jones@fulcrum.com.au wrote: >> > I need an interface to Oracle 8, and am finding that most of the oracle >> > modules out there (except the Digicool one, but I don't have the option of >> > paying for it) are a little out of date with respect to Oracle 8. >> >> I've used the oracledb module (the freebie) from digicool >> with oracle 8, and after the horrible fight to get it linked >> it seemed to work without a problem. I also know someone >> who is using Anthony Baxter's version and it seems to work >> good for him. > > Well, to expand a little on the post I made... I have Anthony Baxter's >oracledb module linked fine with 8.0.5 now. I patched the Makefile to include >${ORACLE_HOME}/rdbms/lib/env_rdbms.mk and then linked with ${TTLIBS}. My >problem was that my test select wasn't working properly. After investigating >further, I find that a "select * from tab" only returns a row at a time when >fetchall()'ed, but a regular table that I make will return all rows on a >fetchall(). This is all a bit dodgy, and may result in the killing of Python >from the project I'm working on. > > Now for the icky bit... looking in the 8.0.4 documentation for OCI, I find >that all the functions used in oracledb are now deprecated. *sigh* > > >> Conceivably (dunno) it should be possible to >> use M.A.Lemburg's mxODBC or (on win32) Bill Tutt's odbc module >> or, if you diverge from Greg Stein's dbapi, Sam Rushing's >> more direct odbc binding too on win32. Dunno if this helps. >> It's all very confusing. > > ODBC isn't an option, unfortunately. > > >> The problem with diversity is it's so diverse, when all >> you wanna do is get the job done! I think I posted a makefile >> for oracle8/oracledbmodule to the dbsig many months ago. > > Well, here's the snippet that works for me: this is the last few lines of >the Makefile... > >include ${ORACLE_HOME}/rdbms/lib/env_rdbms.mk >oradbmodule.o: $(srcdir)/oradbmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -I. -I. -c >$(srcdir)/oradbmodule.c >dbi.o: $(srcdir)/dbi.c; $(CC) $(CCSHARED) $(CFLAGS) -I. -I. -c $(srcdir)/dbi.c >oracledbmodule$(SO): oradbmodule.o dbi.o; $(LDSHARED) oradbmodule.o dbi.o -L$ >{ORACLE_HOME}/lib ${TTLIBS} -lsocket -lgen -ldl -lc -laio -lm -o oracledbmodule$ >(SO) > > (Note that the oradbmodule.o, dbi.o and oracledbmodule$(SO) lines should be >1 line - but my mail program might break them) > > > > Richard > >-- >Richard Jones, developer for the Fulcrum Consulting Group. (03) 9621 2100 >http://www.fulcrum.com.au/ http://alumni.dgs.monash.edu.au/~richard/ > From gstein@lyra.org Fri Dec 4 02:46:44 1998 From: gstein@lyra.org (Greg Stein) Date: Thu, 03 Dec 1998 18:46:44 -0800 Subject: [DB-SIG] Re: oracle db module status References: <199812040237.VAA14461@shell.monmouth.com> Message-ID: <36674D14.58621123@lyra.org> If that is the behavior, then the modules are *wrong*. fetchall() should return *all* the rows, memory-be-damned. The fetchall() method was specified at the request of a number of users; Joel Shprentz was the specific motivator, as I recall -- he had some excellent arguments for its inclusion. Further, fetchmany() should return the number that you request. Any fewer, and that means that there aren't any more (much like a read()). If any module does not obey those rules, then I'd question their compliance to the DBAPI. -g Ronald Hiller wrote: > > I had the same experience as you in that fetchmany() returns a single row > from a large table. > > It appears that there is a limit on the number of things returned by the > fetchmany() call (it is set to 1000 in Anthony Baxter's version). This > still doesn't explain all of the behavior I see, but it helps! > > Anyways, one solution is: > def myfetchmany(cursor): > res = [] > while 1: > r = cursor.fetchone() > if not r: break > res.append(r) > return res > > A look back at the Digicool freebie module shows it always fetches one row > at a time so this will be no worse. > > I had some problems with the Digicool freebie module with core dumps and > infinite loops (always in the cleanup when Python was cleaning up to exit). > > Ron > ========================================================== > Ronald Hiller Graburn Technology, Inc. > Phone: (732) 845-3999 Suite 250 > FAX: (732) 446-6835 716 Newman Springs Road > email: ron@graburn.com Lincroft, NJ 07738 > ========================================================== > > >[cross-posted to DB-SIG, in case someone there cares. I don't subscribe to > >DB-SIG though, so please CC me any relevant followups] > > > >[Aaron_Watters@my-dejanews.com] > >> richard.jones@fulcrum.com.au wrote: > >> > I need an interface to Oracle 8, and am finding that most of the > oracle > >> > modules out there (except the Digicool one, but I don't have the > option of > >> > paying for it) are a little out of date with respect to Oracle 8. > >> > >> I've used the oracledb module (the freebie) from digicool > >> with oracle 8, and after the horrible fight to get it linked > >> it seemed to work without a problem. I also know someone > >> who is using Anthony Baxter's version and it seems to work > >> good for him. > > > > Well, to expand a little on the post I made... I have Anthony Baxter's > >oracledb module linked fine with 8.0.5 now. I patched the Makefile to > include > >${ORACLE_HOME}/rdbms/lib/env_rdbms.mk and then linked with ${TTLIBS}. My > >problem was that my test select wasn't working properly. After investigating > >further, I find that a "select * from tab" only returns a row at a time when > >fetchall()'ed, but a regular table that I make will return all rows on a > >fetchall(). This is all a bit dodgy, and may result in the killing of Python > >from the project I'm working on. > > > > Now for the icky bit... looking in the 8.0.4 documentation for OCI, I > find > >that all the functions used in oracledb are now deprecated. *sigh* > > > > > >> Conceivably (dunno) it should be possible to > >> use M.A.Lemburg's mxODBC or (on win32) Bill Tutt's odbc module > >> or, if you diverge from Greg Stein's dbapi, Sam Rushing's > >> more direct odbc binding too on win32. Dunno if this helps. > >> It's all very confusing. > > > > ODBC isn't an option, unfortunately. > > > > > >> The problem with diversity is it's so diverse, when all > >> you wanna do is get the job done! I think I posted a makefile > >> for oracle8/oracledbmodule to the dbsig many months ago. > > > > Well, here's the snippet that works for me: this is the last few lines > of > >the Makefile... > > > >include ${ORACLE_HOME}/rdbms/lib/env_rdbms.mk > >oradbmodule.o: $(srcdir)/oradbmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -I. > -I. -c > >$(srcdir)/oradbmodule.c > >dbi.o: $(srcdir)/dbi.c; $(CC) $(CCSHARED) $(CFLAGS) -I. -I. -c > $(srcdir)/dbi.c > >oracledbmodule$(SO): oradbmodule.o dbi.o; $(LDSHARED) oradbmodule.o > dbi.o -L$ > >{ORACLE_HOME}/lib ${TTLIBS} -lsocket -lgen -ldl -lc -laio -lm -o > oracledbmodule$ > >(SO) > > > > (Note that the oradbmodule.o, dbi.o and oracledbmodule$(SO) lines > should be > >1 line - but my mail program might break them) > > > > > > > > Richard > > > >-- > >Richard Jones, developer for the Fulcrum Consulting Group. (03) 9621 2100 > >http://www.fulcrum.com.au/ http://alumni.dgs.monash.edu.au/~richard/ > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig -- Greg Stein, http://www.lyra.org/ From ron@graburn.com Fri Dec 4 03:05:50 1998 From: ron@graburn.com (Ronald Hiller) Date: Thu, 03 Dec 1998 22:05:50 -0500 Subject: [DB-SIG] Re: oracle db module status In-Reply-To: <36674D14.58621123@lyra.org> References: <199812040237.VAA14461@shell.monmouth.com> Message-ID: <199812040305.WAA27828@shell.monmouth.com> The digicool freebie module returns all rows to the python caller, but fetches them from Oracle one at a time...hence my "no worse.." comment. A closer read of Anthony Baxter's module source shows that he fetches from Oracle in groups of 1000 rows at a time. However, something in this doesn't seem to work since fetchall() returns a single row on a large table but all rows on a small table. I tried sending Anthony mail, but it seems "that number has been disconnected". I will keep snooping and poking at this. Ron At 06:46 PM 12/3/98 -0800, you wrote: >If that is the behavior, then the modules are *wrong*. fetchall() >should return *all* the rows, memory-be-damned. The fetchall() method >was specified at the request of a number of users; Joel Shprentz was the >specific motivator, as I recall -- he had some excellent arguments for >its inclusion. > >Further, fetchmany() should return the number that you request. Any >fewer, and that means that there aren't any more (much like a read()). > >If any module does not obey those rules, then I'd question their >compliance to the DBAPI. > >-g > >Ronald Hiller wrote: >> >> I had the same experience as you in that fetchmany() returns a single row >> from a large table. >> >> It appears that there is a limit on the number of things returned by the >> fetchmany() call (it is set to 1000 in Anthony Baxter's version). This >> still doesn't explain all of the behavior I see, but it helps! >> >> Anyways, one solution is: >> def myfetchmany(cursor): >> res = [] >> while 1: >> r = cursor.fetchone() >> if not r: break >> res.append(r) >> return res >> >> A look back at the Digicool freebie module shows it always fetches one row >> at a time so this will be no worse. >> >> I had some problems with the Digicool freebie module with core dumps and >> infinite loops (always in the cleanup when Python was cleaning up to exit). >> >> Ron >> ========================================================== >> Ronald Hiller Graburn Technology, Inc. >> Phone: (732) 845-3999 Suite 250 >> FAX: (732) 446-6835 716 Newman Springs Road >> email: ron@graburn.com Lincroft, NJ 07738 >> ========================================================== >> >> >[cross-posted to DB-SIG, in case someone there cares. I don't subscribe to >> >DB-SIG though, so please CC me any relevant followups] >> > >> >[Aaron_Watters@my-dejanews.com] >> >> richard.jones@fulcrum.com.au wrote: >> >> > I need an interface to Oracle 8, and am finding that most of the >> oracle >> >> > modules out there (except the Digicool one, but I don't have the >> option of >> >> > paying for it) are a little out of date with respect to Oracle 8. >> >> >> >> I've used the oracledb module (the freebie) from digicool >> >> with oracle 8, and after the horrible fight to get it linked >> >> it seemed to work without a problem. I also know someone >> >> who is using Anthony Baxter's version and it seems to work >> >> good for him. >> > >> > Well, to expand a little on the post I made... I have Anthony Baxter's >> >oracledb module linked fine with 8.0.5 now. I patched the Makefile to >> include >> >${ORACLE_HOME}/rdbms/lib/env_rdbms.mk and then linked with ${TTLIBS}. My >> >problem was that my test select wasn't working properly. After investigating >> >further, I find that a "select * from tab" only returns a row at a time when >> >fetchall()'ed, but a regular table that I make will return all rows on a >> >fetchall(). This is all a bit dodgy, and may result in the killing of Python >> >from the project I'm working on. >> > >> > Now for the icky bit... looking in the 8.0.4 documentation for OCI, I >> find >> >that all the functions used in oracledb are now deprecated. *sigh* >> > >> > >> >> Conceivably (dunno) it should be possible to >> >> use M.A.Lemburg's mxODBC or (on win32) Bill Tutt's odbc module >> >> or, if you diverge from Greg Stein's dbapi, Sam Rushing's >> >> more direct odbc binding too on win32. Dunno if this helps. >> >> It's all very confusing. >> > >> > ODBC isn't an option, unfortunately. >> > >> > >> >> The problem with diversity is it's so diverse, when all >> >> you wanna do is get the job done! I think I posted a makefile >> >> for oracle8/oracledbmodule to the dbsig many months ago. >> > >> > Well, here's the snippet that works for me: this is the last few lines >> of >> >the Makefile... >> > >> >include ${ORACLE_HOME}/rdbms/lib/env_rdbms.mk >> >oradbmodule.o: $(srcdir)/oradbmodule.c; $(CC) $(CCSHARED) $(CFLAGS) -I. >> -I. -c >> >$(srcdir)/oradbmodule.c >> >dbi.o: $(srcdir)/dbi.c; $(CC) $(CCSHARED) $(CFLAGS) -I. -I. -c >> $(srcdir)/dbi.c >> >oracledbmodule$(SO): oradbmodule.o dbi.o; $(LDSHARED) oradbmodule.o >> dbi.o -L$ >> >{ORACLE_HOME}/lib ${TTLIBS} -lsocket -lgen -ldl -lc -laio -lm -o >> oracledbmodule$ >> >(SO) >> > >> > (Note that the oradbmodule.o, dbi.o and oracledbmodule$(SO) lines >> should be >> >1 line - but my mail program might break them) >> > >> > >> > >> > Richard >> > >> >-- >> >Richard Jones, developer for the Fulcrum Consulting Group. (03) 9621 2100 >> >http://www.fulcrum.com.au/ http://alumni.dgs.monash.edu.au/~richard/ >> > >> >> _______________________________________________ >> DB-SIG maillist - DB-SIG@python.org >> http://www.python.org/mailman/listinfo/db-sig > >-- >Greg Stein, http://www.lyra.org/ > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://www.python.org/mailman/listinfo/db-sig > From richard.jones@fulcrum.com.au Fri Dec 4 03:13:40 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Fri, 04 Dec 1998 14:13:40 +1100 Subject: [DB-SIG] Re: oracle db module status In-Reply-To: Message from Greg Stein of 1998-Dec-3 18:46:44, <36674D14.58621123@lyra.org> Message-ID: <199812040313.OAA09215@icarus.fulcrum.com.au> [I'm on DB-SIG now - don't bother cc'ing me. Thanks for those that did.] [Greg Stein] [Ronald Hiller talks about fetchmany and fetchall not returning the number of rows asked for] > If that is the behavior, then the modules are *wrong*. fetchall() > should return *all* the rows, memory-be-damned. The fetchall() method > was specified at the request of a number of users; Joel Shprentz was the > specific motivator, as I recall -- he had some excellent arguments for > its inclusion. Absolutely - I see the current implementation as being buggy - but only sometimes and I don't have pre-oracle 8 documentation for OCI to figure why it's only works sometimes. If I find time (unlikely) I'll try to convert Anthony's oracledb to using the new Oracle 8 OCI calls. BTW, does anyone know what they mean by "cursors are not used in Release 8"? > Further, fetchmany() should return the number that you request. Any > fewer, and that means that there aren't any more (much like a read()). > > If any module does not obey those rules, then I'd question their > compliance to the DBAPI. Unfortunately, Anthony's in New Zealand at the moment on holidays - I'll bring all this to his attention when he gets back, but I have a feeling that he won't have access to Oracle. Richard ps. Greg, on the oracledb module site that's linked from python.org (ie. ftp://ftp.clark.net/pub/culliton/) you're cited as being a maintainer of a more recent version. Is this true? -- Richard Jones, developer for the Fulcrum Consulting Group. (03) 9621 2100 http://www.fulcrum.com.au/ http://alumni.dgs.monash.edu.au/~richard/ From richard.jones@fulcrum.com.au Fri Dec 4 03:19:24 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Fri, 04 Dec 1998 14:19:24 +1100 Subject: [DB-SIG] Re: oracle db module status In-Reply-To: Message from Ronald Hiller of 1998-Dec-3 22:5:50, <199812040305.WAA27828@shell.monmouth.com> Message-ID: <199812040319.OAA09248@icarus.fulcrum.com.au> [Ronald Hiller] > The digicool freebie module returns all rows to the python caller, but > fetches them from Oracle one at a time...hence my "no worse.." comment. A > closer read of Anthony Baxter's module source shows that he fetches from > Oracle in groups of 1000 rows at a time. Ahhh... sorry for the misunderstanding. > However, something in this doesn't seem to work since fetchall() returns a > single row on a large table but all rows on a small table. I tried sending > Anthony mail, but it seems "that number has been disconnected". I will > keep snooping and poking at this. The thing is though that all the tables I'm accessing are very small - maybe 3 or 4 rows maximum (yes, even TAB) - so it's not a matter of table size for me. It might be a strange problem with select'ing data from the Data Dictionary ... a "select * from all_users" works fine... Anthony just changed jobs - he's also on holidays at the moment. He should be back in a week or so... Richard ps. for the sake of the archives, please trim the quoted email in your replies ;) From gstein@lyra.org Fri Dec 4 03:44:38 1998 From: gstein@lyra.org (Greg Stein) Date: Thu, 03 Dec 1998 19:44:38 -0800 Subject: [DB-SIG] Re: oracle db module status References: <199812040313.OAA09215@icarus.fulcrum.com.au> Message-ID: <36675AA6.62202B1D@lyra.org> Richard Jones wrote: > ... > Unfortunately, Anthony's in New Zealand at the moment on holidays - I'll > bring all this to his attention when he gets back, but I have a feeling that he > won't have access to Oracle. His email seems to be down, too. When you see him, please let him know that I unsubscribed him from thread-sig :-) I probably should have disabled it, but (sigh) I was thinking. > ps. Greg, on the oracledb module site that's linked from python.org (ie. > ftp://ftp.clark.net/pub/culliton/) you're cited as being a maintainer of a more > recent version. Is this true? Nope. While this may not fully explain everything, let me relate a story. It is deep and rich in history, love, and hardships. Truly, an epic that is only beginning... Once upon a time, there was a company named eShop. This small company learned and loved Python, embracing it in all its goodness. The company wanted to play with Oracle, so it developed a new way to be intimate with Oracle -- oracledb. eShop, Python, and Oracle played in private for many months, but the future was not rosy. A titan rumbled along and scooped up eShop in its massive hand. This titan, going by the name of Microsoft, said, "your intimacy with Oracle is nice, but let me introduce you to my friend, ODBC." eShop obliged, under the rough care of this strange titan. oracledb was still nice, but the new ODBC friend was better. Rather than letting the intimacy between Python and oracledb die in disfavor, eShop seeked out a way for the relationship to continue. A secret tryst with Digital Creations soon developed. Of course, it could not really remain secret, but what could poor little eShop do? It had to try. It couldn't break oracledb's heart, after the relationship that they shared. Eventually, it came out. eShop wontonly transferref ownership of oracledb over to Digital Creations. Did oracledb want to go? Maybe. Maybe not. But it was a slave to mighty powers. However, the story ends well. While eShop lingered on within the titan's palm, eventually becoming One with the titan, oracledb flourished. The Others were attracted to the beautiful harmony. oracledb was picked up and cared for, free of the love triangle between its former life partner and that rival, ODBC. oracledb now lives on, free of its former burdens. :-) -- Greg Stein, http://www.lyra.org/ From ron@graburn.com Fri Dec 4 03:49:47 1998 From: ron@graburn.com (Ronald Hiller) Date: Thu, 03 Dec 1998 22:49:47 -0500 Subject: [DB-SIG] Re: oracle db module status In-Reply-To: <199812040319.OAA09248@icarus.fulcrum.com.au> References: Message-ID: <199812040349.WAA16867@shell.monmouth.com> I just put in a couple of printf's in Anthony's code. In one case, the "ofen" function returns 1000 items on each loop, in the other case only 1. I am playing with two tables (both my own), the one that works has 13,000 rows, the one that doesn't has 47,000 rows. This seems higly mysterious ("ofen"??). BTW, I am using Oracle 7.3.2.3, so it's not just an Oracle 8 problem. I've never played with Oracle OCI code before, so I don't know how those functions are *supposed* to work, but this doesn't seem right. When ofen returns a single item the return code is 1405. When it returns lots of rows, all calls except the last have a return code of 0, the last returns 1403. Where are these documented? Ron At 02:19 PM 12/4/98 +1100, you wrote: > > The thing is though that all the tables I'm accessing are very small - >maybe 3 or 4 rows maximum (yes, even TAB) - so it's not a matter of table size >for me. It might be a strange problem with select'ing data from the Data >Dictionary ... a "select * from all_users" works fine... From richard.jones@fulcrum.com.au Fri Dec 4 03:52:09 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Fri, 04 Dec 1998 14:52:09 +1100 Subject: [DB-SIG] Re: oracle db module status Message-ID: <199812040352.OAA09328@icarus.fulcrum.com.au> OK, I lied. It seems there's other tables that oracledb doesn't do the Right Thing when fetchall() is called. I actually got around to implementing the tables for the production system I'm working on - as opposed to the test tables I was using this morning. Guess what? No fetchall(). Grrr. The Perl camp here will be seriously starting to push for translation of the system over to Perl/DBI soon. That would be sad. Richard From richard.jones@fulcrum.com.au Fri Dec 4 04:22:28 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Fri, 04 Dec 1998 15:22:28 +1100 Subject: [DB-SIG] Oracle 8 working now Message-ID: <199812040422.PAA09365@icarus.fulcrum.com.au> [ woohoo! you bet you wish I never joined this list, eh? ] Well, I just replaced the oradbmodule.c file in oracledb-0.2.0pre1 with the oracledb.c file from oracledb-0.1.3 on digicool's site. Even though it's less optimised for large fetches, it _works_. Richard From Martin Sckopke Fri Dec 4 07:41:34 1998 From: Martin Sckopke (Martin Sckopke) Date: Fri, 4 Dec 1998 07:41:34 +0000 Subject: [DB-SIG] Re: oracle db module status In-Reply-To: <199812040349.WAA16867@shell.monmouth.com> References: <199812040319.OAA09248@icarus.fulcrum.com.au> Message-ID: <19981204065740.32239.qmail@gis.ibfs.de> At the moment we're also trying to use the oracledb-module. There seems to be at least one memory leak somewhere in the code. After having run the code for about 24 hours our process has allocated about 40 MB starting from 4. Did anybody look for memory leaks in the code before? Martin -- Martin Sckopke GiS: Gesellschaft für integrierte Systemplanung Junkersstr. 2 Tel.: 06201/50345 69469 Weinheim Fax.: 06201/50366 eMail: m.sckopke@gis.ibfs.de From harri.pasanen@trema.com Fri Dec 4 08:43:15 1998 From: harri.pasanen@trema.com (Harri Pasanen) Date: Fri, 04 Dec 1998 09:43:15 +0100 Subject: [DB-SIG] Are DigiCool's DB interfaces now Open Source (Oracle, Sybase)? References: <199812040352.OAA09328@icarus.fulcrum.com.au> Message-ID: <3667A0A3.925BCBBB@trema.com> I was reading with interest about Principia and Aquaduct going open source from http://lwn.net/ (Linux Weekly News). """Digital Creations has moved ahead with their plans to open up the source code for Principia, an object-based web development platform, and integrate it with Bobo, a popular open source web toolkit also developed by Digital Creations. In fact, they've gone even further and dropped their Aqueduct relational database integration product in as well. The result is a new product, the Z Object Publishing Environment, to be known as "Zope" for short.""" I wonder if this Aqueduct contains DB interfaces, or is it higher level? Just idle thoughts, Harri From mal@lemburg.com Fri Dec 4 09:38:52 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 04 Dec 1998 10:38:52 +0100 Subject: [DB-SIG] Re: oracle db module status References: <199812032317.KAA08786@icarus.fulcrum.com.au> Message-ID: <3667ADAC.5AEAEBF@lemburg.com> Richard Jones wrote: > > > Conceivably (dunno) it should be possible to > > use M.A.Lemburg's mxODBC or (on win32) Bill Tutt's odbc module > > or, if you diverge from Greg Stein's dbapi, Sam Rushing's > > more direct odbc binding too on win32. Dunno if this helps. > > It's all very confusing. > > ODBC isn't an option, unfortunately. > Why not ? You can use ODBC on Windows and Unix (you've got to get drivers from Intersolv for the latter). Oracle reported to work with mxODBC on both platforms and doesn't have the problems you describe, AFAIK. -- Marc-Andre Lemburg Y2000: 392 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From shprentz@bdm.com Fri Dec 4 14:53:45 1998 From: shprentz@bdm.com (Joel Shprentz) Date: Fri, 04 Dec 1998 09:53:45 -0500 Subject: [DB-SIG] Re: oracle db module status (fetchall behavior) In-Reply-To: <36674D14.58621123@lyra.org> References: <199812040237.VAA14461@shell.monmouth.com> Message-ID: <4.1.19981204091748.06ecf110@blat.com> At 06:46 PM 12/3/98 -0800, Greg Stein wrote: >If that is the behavior, then the modules are *wrong*. fetchall() >should return *all* the rows, memory-be-damned. The fetchall() method >was specified at the request of a number of users; Joel Shprentz was the >specific motivator, as I recall -- he had some excellent arguments for >its inclusion. The "specific motivator" recalls ... Many of the usual suspects discussed these issues during a lunch break at the 1995 Python Workshop in Reston, Virginia. As I write this message on a PC with 96 MB of memory, my principal argument seems even more valid: In most cases we know that our computers have ample real and/or virtual memory to hold all the rows that will be returned by an SQL query. When main memory was tiny, programs had to be structured to process each row as it was retrieved. Now object models and program structures can become cleaner and simpler because we can pass a retrieved array of rows to some function that acts upon them. Or, better yet, encapuslate the array and/or individual rows in objects and define methods that act on those objects. I still find uses for fetchone and fetchmany. I use fetchone when I want the first (last, worst, best, etc.) record from a list. For example, the best selling product or the first unprocessed order. I use fetchmany when I want to display a fixed number of results on a screen or when I want the top (bottom, first, last, worst, best, etc.) records from a list. For example, I may want to display only 25 result records on a web page. Or I may want to retrieve Dave Letterman's top 10 list. -- Joel Shprentz (202) 863-3487 BDM Federal, Inc. shprentz@bdm.com 1501 BDM Way McLean, VA 22102 From jim@Digicool.com Fri Dec 4 15:43:09 1998 From: jim@Digicool.com (Jim Fulton) Date: Fri, 04 Dec 1998 15:43:09 +0000 Subject: [DB-SIG] Are DigiCool's DB interfaces now Open Source (Oracle, Sybase)? References: <199812040352.OAA09328@icarus.fulcrum.com.au> <3667A0A3.925BCBBB@trema.com> Message-ID: <3668030D.7F1B089A@digicool.com> Harri Pasanen wrote: > > I was reading with interest about Principia and Aquaduct going > open source from http://lwn.net/ (Linux Weekly News). > > """Digital Creations has moved ahead with their plans to open up the > source code for Principia, an object-based web development platform, and > integrate it with Bobo, a popular open source web toolkit also developed > by Digital Creations. In fact, they've gone even further and dropped > their Aqueduct relational database integration product in as well. The > result is a new product, the Z Object Publishing Environment, to be > known as "Zope" for short.""" > > I wonder if this Aqueduct contains DB interfaces, or is it higher > level? We haven't done alot of DB interfaces. Aqueduct mostly used existing DB interfaces. We do have our own grungy ODBC interface that was written only for Aqueduct that we'll make available. We are de-productifying DCOracle. We'll be supporting it only for existing DCOracle customers and for our consulting clients. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From gstein@lyra.org Fri Dec 4 19:37:39 1998 From: gstein@lyra.org (Greg Stein) Date: Fri, 04 Dec 1998 11:37:39 -0800 Subject: [DB-SIG] Re: oracle db module status References: <199812040319.OAA09248@icarus.fulcrum.com.au> <19981204065740.32239.qmail@gis.ibfs.de> Message-ID: <36683A03.7FF2D544@lyra.org> Martin Sckopke wrote: > > At the moment we're also trying to use the oracledb-module. > There seems to be at least one memory leak somewhere in the code. > After having run the code for about 24 hours our process has > allocated about 40 MB starting from 4. > Did anybody look for memory leaks in the code before? Is it truly a leak, or is 40MB simply the working set? In other words, if you let it go for 48 hours, does it go to 80MB? Or the reverse, where is the memory at 12 hours? -g -- Greg Stein, http://www.lyra.org/ From ron@graburn.com Sat Dec 5 03:38:19 1998 From: ron@graburn.com (Ronald Hiller) Date: Fri, 04 Dec 1998 22:38:19 -0500 Subject: [DB-SIG] oracledb module: why fetchall() doesn't Message-ID: <199812050338.WAA17902@shell.monmouth.com> I have been looking through the Oracle OCI docs and Anthony Baxter's oracledb code. It appears the reason it sometimes fails to deliver all rows of a query with a fetchall() is due to the handling of NULL. The ofen() call will return an ORA-01405 when it encounters a NULL column. It will return all rows up to and including the one with the NULL, but none beyond that. The Digicool module retrieved rows one at a time and used the 1405 code to insert a Python "None" into the returned list. Therefore, it works correctly. The OCI docs say that "indicator variables" (basically a parallel array that gets filled in by Oracle with the real/Null info) is the way to go. Now, I will poke around to see how hard it is to implement this... Ron From ron@graburn.com Sat Dec 5 11:54:31 1998 From: ron@graburn.com (Ronald Hiller) Date: Sat, 05 Dec 1998 06:54:31 -0500 Subject: [DB-SIG] oracledb module: why fetchall() doesn't In-Reply-To: <199812050338.WAA17902@shell.monmouth.com> Message-ID: <199812051154.GAA10932@shell.monmouth.com> I have a fix for fetchall() and fetchmany() in Anthony Baxter's module. I will send it to him when he gets back. In the interim, if anyone wants it, I can send it to you. Ron From richard.jones@fulcrum.com.au Mon Dec 7 21:41:37 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Tue, 08 Dec 1998 08:41:37 +1100 Subject: [DB-SIG] oracledb module: why fetchall() doesn't In-Reply-To: Message from Ronald Hiller of 1998-Dec-5 6:54:31, <199812051154.GAA10932@shell.monmouth.com> Message-ID: <199812072141.IAA13185@icarus.fulcrum.com.au> [Ronald Hiller] > I have a fix for fetchall() and fetchmany() in Anthony Baxter's module. I > will send it to him when he gets back. In the interim, if anyone wants it, > I can send it to you. Please :) Richard From ron@graburn.com Tue Dec 8 01:40:05 1998 From: ron@graburn.com (Ronald Hiller) Date: Mon, 07 Dec 1998 20:40:05 -0500 Subject: [DB-SIG] oracledb module: why fetchall() doesn't In-Reply-To: <199812072141.IAA13185@icarus.fulcrum.com.au> References: Message-ID: <199812080138.UAA09088@shell.monmouth.com> My patch is available from . I believe it corrects the problem with Anthony's module not returning all rows on a fetchall() or fetchmany(). I have tried to contact Anthony, but his old email address didn't work...If anyone has a newer/better address, please let me know. This should really be incorporated into his code (so there is only one origin for this). Ron From richard.jones@fulcrum.com.au Fri Dec 11 04:55:04 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Fri, 11 Dec 1998 15:55:04 +1100 Subject: [DB-SIG] oracledb module 0.2pre1 Message-ID: <199812110455.PAA17508@icarus.fulcrum.com.au> Strangenesses occur in the 0.2pre1 oracledb module when fetchall() is called. Basically, the description gets doubled up. I added the following simple fix (which works for me, but I was really only guessing ;) Richard [This isn't a diff or anything really useful - but then I only added 4 lines] static int oraCurs_OutputBindings(oraCursObject *self) { sb2 vtype; sb4 vsize; sb1 name[256]; /*sb2 tempvar;*/ sb4 nsize = sizeof(name); sword pos = 1; sb4 dsize; sb2 prec, scale, nullok; if (self->cda[0].ft != 4) { /* Stop here if not a SELECT ! */ self->n_columns = 0; return 1; } + if (self->description) { + Py_DECREF(self->description); + } + self->description = PyList_New(0); while (odescr(self->cda, pos, &vsize, &vtype, name, &nsize, &dsize, &prec, &scale, &nullok) == 0) { PyObject *new_tuple; name[nsize] = 0; if (vtype == SQLT_LNG) { vsize = self->max_output; } From ron@graburn.com Fri Dec 11 11:08:44 1998 From: ron@graburn.com (Ronald Hiller) Date: Fri, 11 Dec 1998 06:08:44 -0500 Subject: [DB-SIG] oracledb module 0.2pre1 In-Reply-To: <199812110455.PAA17508@icarus.fulcrum.com.au> Message-ID: <199812111107.GAA10695@shell.monmouth.com> Richard, Do you have an example of the problem? Please explain in more detail. I'd like to know if I have it too ;-). Thanks, Ron At 03:55 PM 12/11/98 +1100, you wrote: > > Strangenesses occur in the 0.2pre1 oracledb module when fetchall() is >called. Basically, the description gets doubled up. I added the following >simple fix (which works for me, but I was really only guessing ;) > > > Richard From richard.jones@fulcrum.com.au Wed Dec 16 04:44:04 1998 From: richard.jones@fulcrum.com.au (Richard Jones) Date: Wed, 16 Dec 1998 15:44:04 +1100 Subject: [DB-SIG] oracledb module 0.2pre1 LONGs? Message-ID: <199812160444.PAA25582@icarus.fulcrum.com.au> Does anyone have LONG fetching working with 0.2pre1? Basically, the current oracledb 0.2pre1 can't figure the size of the long to fetch and thus fetches nothing. Richard ps. Anthony's around and will be releasing 0.2pre2 RSN with patches that fix the stuff we've been discussing over the last week or so. He doesn't have a fix for this problem though. From mal@lemburg.com Wed Dec 16 10:45:35 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 16 Dec 1998 11:45:35 +0100 Subject: [DB-SIG] oracledb module 0.2pre1 LONGs? References: <199812160444.PAA25582@icarus.fulcrum.com.au> Message-ID: <36778F4F.309A6744@lemburg.com> Richard Jones wrote: > > Does anyone have LONG fetching working with 0.2pre1? > > Basically, the current oracledb 0.2pre1 can't figure the size of the long to > fetch and thus fetches nothing. I'm not familiar with OCI, but... Couldn't the module just go and fetch the data in fixed sized chunks until the API returns less data than the chunk size ? In ODBC there's a SQLGetData API that works much like that (and is used for LONGs and columns for which the exact data element size is undefined at bind time). -- Marc-Andre Lemburg Y2000: 380 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From sjturner@ix.netcom.com Thu Dec 17 22:01:05 1998 From: sjturner@ix.netcom.com (Stephen J. Turner) Date: Thu, 17 Dec 1998 17:01:05 -0500 Subject: [DB-SIG] Call for Bertil Reinhammar... Message-ID: <36797F21.74C3FBE1@ix.netcom.com> Hello all, I tried contacting Bertil at the address given in the informixdb distribution (Bertil_Reinhammar@ivab.se), only to have my email returned 'User unknown'. Does anyone know either: - What is Bertil's new email address? - Who has assumed responsibility for maintaining informixdb in his stead? Thanks, Stephen From sjturner@ix.netcom.com Thu Dec 17 22:25:42 1998 From: sjturner@ix.netcom.com (Stephen J. Turner) Date: Thu, 17 Dec 1998 17:25:42 -0500 Subject: [DB-SIG] dbi module patch Message-ID: <367984E6.5CD21BCF@ix.netcom.com> This is a multi-part message in MIME format. --------------4A3D4AB30CDD76090C2CB53A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is a patch for the dbi module. It fixes an obscure little reference count bug that only surfaces if a dbiRaw object is converted to string (e.g., via the str function). Sorry for the direct post to the SIG. I'd have contacted the various maintainers directly, but I have no idea just how many of the DB-API implementations might share the same dbi source file (I gave up checking after informixdb, kinfxdb, oracledb and ctsybase). -- Stephen J. Turner --------------4A3D4AB30CDD76090C2CB53A Content-Type: text/plain; charset=us-ascii; name="dbi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dbi.patch" Index: dbi.c =================================================================== RCS file: /cvsroot/python/informixdb/dbi.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- dbi.c 1998/09/15 17:40:47 1.1.1.1 +++ dbi.c 1998/12/17 16:50:50 1.2 @@ -84,6 +84,13 @@ #endif } +static PyObject *rawStr(PyObject *o) +{ + PyObject *val = dbiValue(o); + Py_INCREF(val); + return val; +} + #define delg(a) dbiValue(a)->ob_type->tp_as_number static PyObject* dt_nb_add(PyObject* a, PyObject* b) @@ -189,7 +196,7 @@ 0, /**tp_as_mapping */ 0, /*tp_hash */ 0, /*tp_call */ - dbiValue /*tp_str */ + rawStr /*tp_str */ } ; static PyTypeObject DbiRowId_Type = --------------4A3D4AB30CDD76090C2CB53A-- From arw@ifu.net Fri Dec 18 14:51:17 1998 From: arw@ifu.net (Aaron Watters) Date: 18 Dec 1998 14:51:17 -0000 Subject: [DB-SIG] Call for Bertil Reinhammar... In-Reply-To: <36797F21.74C3FBE1@ix.netcom.com> Message-ID: <19981218145117.6581.qmail@findmail.com> Hello all, > > I tried contacting Bertil at the address given in the informixdb > distribution (Bertil_Reinhammar@ivab.se), only to have my email returned > 'User unknown'. > > Does anyone know either: > - What is Bertil's new email address? > - Who has assumed responsibility for maintaining informixdb in his > stead? In the event there is noone supporting the module, maybe consider switching to mxODBC, since it seems informix supports odbc, and I know M.A.L. will support it. -- Aaron Watters === But really the kid who said "the emperor has no cloths" was beheaded. ----- See the original message at http://www.egroups.com/list/db-sig/?start=591 From mal@lemburg.com Sat Dec 19 13:03:13 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 19 Dec 1998 14:03:13 +0100 Subject: [DB-SIG] Call for Bertil Reinhammar... References: <19981218145117.6581.qmail@findmail.com> Message-ID: <367BA411.9853F93@lemburg.com> Aaron Watters wrote: > > Hello all, > > > > I tried contacting Bertil at the address given in the informixdb > > distribution (Bertil_Reinhammar@ivab.se), only to have my email returned > > 'User unknown'. > > > > Does anyone know either: > > - What is Bertil's new email address? > > - Who has assumed responsibility for maintaining informixdb in his > > stead? > > In the event there is noone supporting the > module, maybe consider switching to mxODBC, > since it seems informix supports odbc, and > I know M.A.L. will support it. If running on Unix, you'll need a third-party ODBC driver from e.g. InterSolv or OpenLink. The setup should be fairly easy to do. On Windows you can always use the Windows ODBC Manager via mxODBC or the win32 odbc.pyd. More infos are available here: http://starship.skyport.net/~lemburg/mxODBC.html A new version 1.0.0 is due to be released soon. Thanks for the plug, Aaron ;-) -- Marc-Andre Lemburg Y2000: 377 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : ---------------------------------------------------------