Looking for python compliant NXDs

From nicolas.torzec@rd.francetelecom.com Fri Feb 1 10:06:20 2002 From: nicolas.torzec@rd.francetelecom.com (TORZEC Nicolas thesard FTRD/DIH/LAN) Date: Fri, 1 Feb 2002 11:06:20 +0100 Subject: [DB-SIG] Looking for python compliant NXDs Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-a778d9e1-1656-11d6-b1e4-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB08.18917B00" ------_=_NextPart_001_01C1AB08.18917B00 Content-Type: text/plain; charset="iso-8859-1" Dear All, I have many (more than 200.000) but small (less than 5Ko) XML files representing a hierarchically organized annotated corpora. I have planed to store this files in an XML database in order to make the management of the corpus easier, but I can not decide on what DBMS to choose. Python being my favorite scripting language, I would like to access my data and build specialized administration tools by the mean of programs written in Python. So, in your own opinion, what XML DBMS should I use to store my data? Many thanks in advance, Nicolas. PS : I'm experienced in Relational DataBases (Oracle 8i) and in Object-Oriented Databases (O2), but I would prefer to work with an open source DBMS. ___________________________________________ Nicolas TORZEC Ph.D Student France Telecom R&D - DIH/IPS 2, avenue Pierre Marzin, 22307 Lannion Cedex, France Tel : +33 2 96 05 31 36 Email : nicolas.torzec@rd.francetelecom.com ____________________________________________ ------_=_NextPart_001_01C1AB08.18917B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking for python compliant NXDs

Dear All,

I have many (more than 200.000) but small (less than = 5Ko) XML files representing a hierarchically organized annotated = corpora.

I have planed to store this files in an XML database = in order to make the management of the corpus easier, but I can not = decide on what DBMS to choose.

Python being my favorite scripting language, I would = like to access my data and build specialized administration tools by = the mean of programs written in Python.

So, in your own opinion, what XML DBMS should I use = to store my data?

Many thanks in advance,
Nicolas.

PS : I'm experienced in Relational DataBases (Oracle = 8i) and in Object-Oriented Databases (O2), but I would prefer to work = with an open source DBMS.

___________________________________________

Nicolas TORZEC

Ph.D Student
France Telecom R&D - DIH/IPS

2, avenue Pierre Marzin,
22307 Lannion Cedex,
France

Tel : +33 2 96 05 31 36
Email : nicolas.torzec@rd.francetelecom.com
____________________________________________

------_=_NextPart_001_01C1AB08.18917B00-- ------=_NextPartTM-000-a778d9e1-1656-11d6-b1e4-00508b69ab48-- From veillard@redhat.com Fri Feb 1 10:13:44 2002 From: veillard@redhat.com (Daniel Veillard) Date: Fri, 1 Feb 2002 05:13:44 -0500 Subject: [DB-SIG] Re: [XML-SIG] Looking for python compliant NXDs In-Reply-To: ; from nicolas.torzec@rd.francetelecom.com on Fri, Feb 01, 2002 at 11:06:20AM +0100 References: Message-ID: <20020201051344.T29819@redhat.com> On Fri, Feb 01, 2002 at 11:06:20AM +0100, TORZEC Nicolas thesard FTRD/DIH/LAN wrote: > Dear All, > > I have many (more than 200.000) but small (less than 5Ko) XML files > representing a hierarchically organized annotated corpora. > I have planed to store this files in an XML database in order to make the > management of the corpus easier, but I can not decide on what DBMS to > choose. > Python being my favorite scripting language, I would like to access my data > and build specialized administration tools by the mean of programs written > in Python. > > So, in your own opinion, what XML DBMS should I use to store my data? > > Many thanks in advance, > Nicolas. > > > PS : I'm experienced in Relational DataBases (Oracle 8i) and in > Object-Oriented Databases (O2), but I would prefer to work with an open > source DBMS. Then use Postgresql or MySQL http://www.postgresql.org/ http://www.mysql.com/ Both use SQL and can be used from Python, you should feel at home. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mal@lemburg.com Fri Feb 1 10:42:33 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 01 Feb 2002 11:42:33 +0100 Subject: [DB-SIG] Re: [XML-SIG] Looking for python compliant NXDs References: <20020201051344.T29819@redhat.com> Message-ID: <3C5A7119.40478EB@lemburg.com> Daniel Veillard wrote: > > On Fri, Feb 01, 2002 at 11:06:20AM +0100, TORZEC Nicolas thesard FTRD/DIH/LAN wrote: > > Dear All, > > > > I have many (more than 200.000) but small (less than 5Ko) XML files > > representing a hierarchically organized annotated corpora. > > I have planed to store this files in an XML database in order to make the > > management of the corpus easier, but I can not decide on what DBMS to > > choose. > > Python being my favorite scripting language, I would like to access my data > > and build specialized administration tools by the mean of programs written > > in Python. > > > > So, in your own opinion, what XML DBMS should I use to store my data? > > > > Many thanks in advance, > > Nicolas. > > > > > > PS : I'm experienced in Relational DataBases (Oracle 8i) and in > > Object-Oriented Databases (O2), but I would prefer to work with an open > > source DBMS. > > Then use Postgresql or MySQL > http://www.postgresql.org/ > http://www.mysql.com/ > > Both use SQL and can be used from Python, you should feel at home. I'll add SAP DB to that list: http://www.sapdb.org/ It's high performance, full SQL-92, has an Oracle SQL emulation, stored procedures, in-process backups, etc. etc. and it's Open Source ! (I wonder why SAP DB is not receiving more attention in the Open Source world...) There are native database interfaces for all of these or you add another layer of abstraction and talk to them using mxODBC. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From veillard@redhat.com Fri Feb 1 11:00:40 2002 From: veillard@redhat.com (Daniel Veillard) Date: Fri, 1 Feb 2002 06:00:40 -0500 Subject: [DB-SIG] Re: [XML-SIG] Looking for python compliant NXDs In-Reply-To: <3C5A7119.40478EB@lemburg.com>; from mal@lemburg.com on Fri, Feb 01, 2002 at 11:42:33AM +0100 References: <20020201051344.T29819@redhat.com> <3C5A7119.40478EB@lemburg.com> Message-ID: <20020201060040.U29819@redhat.com> On Fri, Feb 01, 2002 at 11:42:33AM +0100, M.-A. Lemburg wrote: > Daniel Veillard wrote: > > Then use Postgresql or MySQL > > http://www.postgresql.org/ > > http://www.mysql.com/ > > > > Both use SQL and can be used from Python, you should feel at home. > > I'll add SAP DB to that list: > http://www.sapdb.org/ Right, > It's high performance, full SQL-92, has an Oracle SQL emulation, > stored procedures, in-process backups, etc. etc. and it's > Open Source ! (I wonder why SAP DB is not receiving more attention > in the Open Source world...) Because it was not developped within the Open source world and that late pluggers like those have a hard time to grow a community independantly of the quality of their source. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From zammon@libero.it Fri Feb 1 10:59:25 2002 From: zammon@libero.it (zammon@libero.it) Date: Fri, 01 Feb 2002 11:59:25 +0100 Subject: [DB-SIG] about dictfetch References: <20020201051344.T29819@redhat.com> <3C5A7119.40478EB@lemburg.com> Message-ID: <3C5A750D.5020703@libero.it> Hi all, I see psycopg has thre very useful cursor methods; dictfetchone(), dictfetchmany() and dictfetchall() I find not those methods defined on Python Database API Specification 2.0 Someone can tell me why those methods are not considered neccessaries ? zammon From nicolas.torzec@rd.francetelecom.com Fri Feb 1 11:06:02 2002 From: nicolas.torzec@rd.francetelecom.com (TORZEC Nicolas thesard FTRD/DIH/LAN) Date: Fri, 1 Feb 2002 12:06:02 +0100 Subject: [DB-SIG] Looking for python compliant NXDs Message-ID: Thank you all for your help. I'm agree that using an classical relational DBMS (like postgres or mysql that I have both already used in the past) would be an "a priori" easy storage solution. But, three problems would occur : 1) Mapping my XML data (semi-structured data based on complex TEI-like DTDs/Schemas) into the rigid relational model underlying the relational DBMSs is not a picnic! I have read on XML.com that tools exists for this kind of work? 2) As this mapping is not guaranted to be bidirectional, I'm not sure that the data I could retrieve will be really identical to the original one! 2) Exploiting (i.e. adding, removing, selecting, extracting, reformating, analyzing) my collections of XML data through an SQL interface is not very satisfying for me. May be using the technologies associated to XML (Xpath, Xupdate, XSL, DOM ...) directly on the data stored in the DataBase would make the database administration/exploitation easier ? Nicolas. -----Original Message----- From: Daniel Veillard [mailto:veillard@redhat.com] Sent: vendredi 1 fevrier 2002 12:01 To: M.-A. Lemburg Cc: TORZEC Nicolas thesard FTRD/DIH/LAN; 'db-sig@python.org' Subject: Re: [DB-SIG] Re: [XML-SIG] Looking for python compliant NXDs On Fri, Feb 01, 2002 at 11:42:33AM +0100, M.-A. Lemburg wrote: > Daniel Veillard wrote: > > Then use Postgresql or MySQL > > http://www.postgresql.org/ > > http://www.mysql.com/ > > > > Both use SQL and can be used from Python, you should feel at home. > > I'll add SAP DB to that list: > http://www.sapdb.org/ Right, > It's high performance, full SQL-92, has an Oracle SQL emulation, > stored procedures, in-process backups, etc. etc. and it's > Open Source ! (I wonder why SAP DB is not receiving more attention > in the Open Source world...) Because it was not developped within the Open source world and that late pluggers like those have a hard time to grow a community independantly of the quality of their source. Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mal@lemburg.com Fri Feb 1 11:19:04 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 01 Feb 2002 12:19:04 +0100 Subject: [DB-SIG] about dictfetch References: <20020201051344.T29819@redhat.com> <3C5A7119.40478EB@lemburg.com> <3C5A750D.5020703@libero.it> Message-ID: <3C5A79A8.66168A37@lemburg.com> "zammon@libero.it" wrote: > > Hi all, > > I see psycopg has thre very useful cursor methods; dictfetchone(), > dictfetchmany() and dictfetchall() > I find not those methods defined on Python Database API Specification 2.0 > Someone can tell me why those methods are not considered neccessaries ? Please see the archives of this mailing list. This is a FAQ (even though there's no FAQ entry yet ;-). """ A very common question on the DB-SIG mailing list is how to construct a dictionary out of the tuples returned by .fetchxxx(). There are several existing tools available which provide helpers for this task. Most of them use the approach of using the column names defined in the cursor attribute .description as basis for the keys in the row dictionary. Note that the reason for not extending the DB API specification to also support dictionary return values for the .fetchxxx() methods is that this approach has several drawbacks: * Some databases don't support case-sensitive column names or auto-convert them to all lowercase or all uppercase characters. * Columns in the result set which are generated by the query (e.g. using SQL functions) don't map to table column names and databases usually generate names for these columns in a very database specific way. As a result, accessing the columns through dictionary keys varies between databases and makes writing portable code impossible. """ This text will go into the DB API 2.0 update which I'll prepare later today. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From magnus@thinkware.se Fri Feb 1 12:01:29 2002 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Fri, 01 Feb 2002 13:01:29 +0100 Subject: Open Source RDBMs Re: [DB-SIG] Re: [XML-SIG] Looking for python compliant NXDs In-Reply-To: <20020201051344.T29819@redhat.com> References: Message-ID: <5.1.0.14.0.20020201114416.0365c658@mail.irrblosset.se> At 05:13 2002-02-01 -0500, Daniel Veillard wrote: > Then use Postgresql or MySQL > http://www.postgresql.org/ > http://www.mysql.com/ > > Both use SQL and can be used from Python, you should feel at home. There are a few more now. For instance: The Interbase derivate Firebird, http://firebird.sourceforge.net/ which is supported by the kinterbasDB http://kinterbasdb.sourceforge.net/ Python= DBU. Then there is the Adabas D derivate SAP DB http://www.sapdb.org/ which has a Python driver as well. (This is from R/3 maker SAP AG.) Both these are open source versions of commercial products that have been around for many years. I think all four are viable alternatives, but of course it depends on your needs. MySQL has only have support for transactions for a rather short time, so I don't know how reliable and fast that is. Does it still not have proper subqueries? Anyway, it seems all four are active and well supported projects. I would imagine postgresql and mysql are much more spread in the open source community, and there are third party books about them etc. On the other hand, SAP DB has plenty of docs, and other advantages such as a number of paid SAP AG developers working with it and Python APIs not only for the database server but also for the DBA tools. I'm not sure about Firebird, buth there seems to be a lot of resources (e.g. http://www.ibphoenix.com/ ) and an active community developing the software. --=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 harri.pasanen@trema.com Fri Feb 1 12:32:50 2002 From: harri.pasanen@trema.com (Harri Pasanen) Date: Fri, 1 Feb 2002 13:32:50 +0100 (CET) Subject: Re[2]: [DB-SIG] Looking for python compliant NXDs In-Reply-To: References: Message-ID: <200202011232.NAA11995@mark.labs.trema.com> On Fri, 1 Feb 2002 12:06:02 +0100 TORZEC Nicolas thesard FTRD/DIH/LAN wrote: > Thank you all for your help. > > I'm agree that using an classical relational DBMS (like postgres or mysql > that I have both already used in the past) would be an "a priori" easy > storage solution. > > But, three problems would occur : > 1) Mapping my XML data (semi-structured data based on complex TEI-like > DTDs/Schemas) into the rigid relational model underlying the relational > DBMSs is not a picnic! I have read on XML.com that tools exists for this > kind of work? > 2) As this mapping is not guaranted to be bidirectional, I'm not sure > that > the data I could retrieve will be really identical to the original one! > 2) Exploiting (i.e. adding, removing, selecting, extracting, reformating, > analyzing) my collections of XML data through an SQL interface is not > very > satisfying for me. May be using the technologies associated to XML > (Xpath, > Xupdate, XSL, DOM ...) directly on the data stored in the DataBase would > make the database administration/exploitation easier ? > > Nicolas. > > You might also want to check out MetaKit, http://www.equi4.com/metakit/. >From its blurb: "MetaKit fills the gap between flat-file, relational, object-oriented, and tree-structured databases, supporting relational joins, serialization, nested structures, and instant schema evolution." Not sure how well it will scale to your purposes though. -Harri > > > -----Original Message----- > From: Daniel Veillard [mailto:veillard@redhat.com] > Sent: vendredi 1 fevrier 2002 12:01 > To: M.-A. Lemburg > Cc: TORZEC Nicolas thesard FTRD/DIH/LAN; 'db-sig@python.org' > Subject: Re: [DB-SIG] Re: [XML-SIG] Looking for python compliant NXDs > > > On Fri, Feb 01, 2002 at 11:42:33AM +0100, M.-A. Lemburg wrote: > > Daniel Veillard wrote: > > > Then use Postgresql or MySQL > > > http://www.postgresql.org/ > > > http://www.mysql.com/ > > > > > > Both use SQL and can be used from Python, you should feel at home. > > > > I'll add SAP DB to that list: > > http://www.sapdb.org/ > > Right, > > > It's high performance, full SQL-92, has an Oracle SQL emulation, > > stored procedures, in-process backups, etc. etc. and it's > > Open Source ! (I wonder why SAP DB is not receiving more attention > > in the Open Source world...) > > Because it was not developped within the Open source world and that > late pluggers like those have a hard time to grow a community > independantly > of the quality of their source. > > Daniel > From jim@zope.com Sun Feb 3 19:37:36 2002 From: jim@zope.com (Jim Fulton) Date: Sun, 03 Feb 2002 14:37:36 -0500 Subject: [DB-SIG] Re: ANNOUNCE: Python 10 Birds of a Feather session on a Python distributed transaction framework References: <3C51F8F8.71613AE5@zope.com> Message-ID: <3C5D9180.69900D03@zope.com> This BOF got moved to Tuesday evening at 8pm. BTW, is there someone familiar with XA or the CORBA transaction service who plaqns to attend? If so, please let me know. Jim Jim Fulton wrote: > > We plan to have a Birds of a Feather (BOF) session at the Python 10 > Conference, http://python10.org, on a Python distributed transaction > framework. > > The Zope object database, ZODB, includes frameworks > for persistence and transaction management. These frameworks > depend very little on the rest of ZODB and will be factored > out of ZODB and made into separate packages in the next generation > of ZODB, ZODB 4. > > We have experience using the transaction framework > with other persistence mechanisms in Zope, including relational > databases and the light-weight directory access protocol, LDAP. > This allows distributed transactions to be coordinated among > multiple database systems. If a transaction is committed or rolled > back, the commit or rollback happens for each of the participating > databases. This is very useful. It would be useful to make this > capability available to other Python applications. > > In particular, it would be worthwhile to explore integrating > distributed transactions with the Python database API to make it > easier to coordinate among multiple databases and to better support > distributed transactions in the Python database API, for example by > including interfaces to underlying distributed-transaction APIs not > currently exposed by the Python database API. > > We'd like to kick off an effort to design a transaction framework > to encompass ZODB, relational databases, and other persistence > systems. > > The talk BOF begin with a presentation of the ZODB Transaction > framework. > > The BOF will take place at lunch time on Tuesday, February 5. > > Jim > > -- > Jim Fulton mailto:jim@zope.com Python Powered! > CTO (888) 344-4332 http://www.python.org > Zope Corporation http://www.zope.com http://www.zope.org -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org From edgar.aschenbrenner@lbc.liebherr.com Mon Feb 4 09:30:36 2002 From: edgar.aschenbrenner@lbc.liebherr.com (Aschenbrenner Edgar (LBC)) Date: Mon, 4 Feb 2002 10:30:36 +0100 Subject: [DB-SIG] (no subject) Message-ID: <4B50B232596FD411AB6700D0B746CA7D105CE7@herkules.ilbc.liebherr.com> Mit freundlichen Gr=FC=DFen Edgar Aschenbrenner Liebherr-Werk Biberach GmbH TB-ST Tel. +49 (0) 7351-41 2398 Fax +49 (0) 7351-41 2854 mailto:edgar.aschenbrenner@lbc.liebherr.com From gstein@lyra.org Mon Feb 4 11:58:07 2002 From: gstein@lyra.org (Greg Stein) Date: Mon, 4 Feb 2002 03:58:07 -0800 Subject: [DB-SIG] SQL statement parse for Oracle In-Reply-To: <3C19CC1A.103B8FFB@lemburg.com>; from mal@lemburg.com on Fri, Dec 14, 2001 at 10:53:30AM +0100 References: <000001c18470$eaa96c60$262a949f@konts.lv> <3C19CC1A.103B8FFB@lemburg.com> Message-ID: <20020204035807.E24602@lyra.org> On Fri, Dec 14, 2001 at 10:53:30AM +0100, M.-A. Lemburg wrote: >... > Perhaps I should add a .prepare() method to the set of standard > DB API extensions though ?! Why? What's the point? You're just adding more APIs, but with no benefit. The whole concept of a prepare() is to get a cursor with a prepared statement which you can execute over and over. The existing API provides for that, for those databases which can support such a concept. Adding prepare() only monkeys up the interface. Now you have a separate call. But wait! That call might not do anything. It just seems senseless to keep throwing more and more APIs in. When the functionality is *already* there, then keep the API simple. Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Mon Feb 4 12:42:08 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 04 Feb 2002 13:42:08 +0100 Subject: [DB-SIG] SQL statement parse for Oracle References: <000001c18470$eaa96c60$262a949f@konts.lv> <3C19CC1A.103B8FFB@lemburg.com> <20020204035807.E24602@lyra.org> Message-ID: <3C5E81A0.18FE1EE3@lemburg.com> Hi Greg, welcome back to the list :-) > On Fri, Dec 14, 2001 at 10:53:30AM +0100, M.-A. Lemburg wrote: > >... > > Perhaps I should add a .prepare() method to the set of standard > > DB API extensions though ?! > > Why? What's the point? > > You're just adding more APIs, but with no benefit. The whole concept of a > prepare() is to get a cursor with a prepared statement which you can execute > over and over. The existing API provides for that, for those databases which > can support such a concept. Sure, but only by actually executing the statement. That may not be what you want, though, e.g. testing whether a SQL statement is valid or not is not possible using the existing DB API methods since you always execute the statement. It is also not possible to setup a few prepared cursors before actually using them for execution. The latter is sometimes needed in cursor pools where you want to pre-allocate resources for a number of predefined SQL commands. > Adding prepare() only monkeys up the interface. Now you have a separate > call. But wait! That call might not do anything. .prepare() is not needed in the sense that you have to call it to execute SQL; .execute() will do the .prepare() for you. > It just seems senseless to keep throwing more and more APIs in. When the > functionality is *already* there, then keep the API simple. We are keeping the API simple. The .prepare() method as well as a bunch of other methods are only standardized *extensions* to the DB API, meaning that if a DB API module author wants to extend the functionality of the module in one of these ways, he should try to stick to these recommendations rather than try to reinvent the wheel in some non-standard way. The DB API extensions are not part of what is required for DB API compatibility. They only form guidelines for DB API extensions which have become rather common in existing DB API compatible packages. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From matt@zope.com Mon Feb 4 14:12:17 2002 From: matt@zope.com (Matthew T. Kromer) Date: Mon, 04 Feb 2002 09:12:17 -0500 Subject: [DB-SIG] SQL statement parse for Oracle References: <000001c18470$eaa96c60$262a949f@konts.lv> <3C19CC1A.103B8FFB@lemburg.com> <20020204035807.E24602@lyra.org> <3C5E81A0.18FE1EE3@lemburg.com> Message-ID: <3C5E96C1.1040902@zope.com> M.-A. Lemburg wrote: > >.prepare() is not needed in the sense that you have to call it >to execute SQL; .execute() will do the .prepare() for you. > > For what it's worth, I make the DCOracle2 driver return the statement type processed from prepare() and execute(). Many people find this awkward as a result from execute() since they were expecting something like number of lines processed (which instead is an attribute). However, its the only good way to figure out what the RDBMS thought of the statement you sent in (was it a SELECT, INSERT, PL/SQL BEGIN, DML, etc.). -- Matt Kromer Zope Corporation http://www.zope.com/ From gstein@lyra.org Mon Feb 4 20:45:17 2002 From: gstein@lyra.org (Greg Stein) Date: Mon, 4 Feb 2002 12:45:17 -0800 Subject: [DB-SIG] SQL statement parse for Oracle In-Reply-To: <3C5E81A0.18FE1EE3@lemburg.com>; from mal@lemburg.com on Mon, Feb 04, 2002 at 01:42:08PM +0100 References: <000001c18470$eaa96c60$262a949f@konts.lv> <3C19CC1A.103B8FFB@lemburg.com> <20020204035807.E24602@lyra.org> <3C5E81A0.18FE1EE3@lemburg.com> Message-ID: <20020204124517.F25181@lyra.org> On Mon, Feb 04, 2002 at 01:42:08PM +0100, M.-A. Lemburg wrote: > Hi Greg, > > welcome back to the list :-) :-) >... > Sure, but only by actually executing the statement. That may not be > what you want, though, e.g. testing whether a SQL statement is valid > or not is not possible using the existing DB API methods since you > always execute the statement. For those cases where you actually need to test some random SQL statement, you're right. How often does that truly happen? [ rhetorical question; the answer is below... ] > It is also not possible to setup a > few prepared cursors before actually using them for execution. The Setting up cursors beforehand is a rather bogus reason. You're just shifting the timing of the preparation. The app will perform the same if you wait for the first usage. And if the cursors don't ever get used, then you actually have a benefit :-) >... > > Adding prepare() only monkeys up the interface. Now you have a separate > > call. But wait! That call might not do anything. > > .prepare() is not needed in the sense that you have to call it > to execute SQL; .execute() will do the .prepare() for you. Of course :-) [ I learned all about prepare() back in '89 when I worked for Oracle... ] > > It just seems senseless to keep throwing more and more APIs in. When the > > functionality is *already* there, then keep the API simple. > > We are keeping the API simple. > > The .prepare() method as well as > a bunch of other methods are only standardized *extensions* to the > DB API, Ah. Now we have the answer :-) If it is described as a standard extension, then everything is hunky dory... hehe > The DB API extensions are not part of what is required for DB API > compatibility. They only form guidelines for DB API extensions > which have become rather common in existing DB API compatible > packages. Yup. It was a bit unclear whether you were talking about extending the DB API interface, or adding to the DB API Extensions. All clear now! Thanks. /me returns to lurking... :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From mal@lemburg.com Mon Feb 4 22:45:42 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 04 Feb 2002 23:45:42 +0100 Subject: [DB-SIG] Update of the DB API 2.0 Spec Message-ID: <3C5F0F16.31F12D17@lemburg.com> As promised, I've integrated the optional DB API extension definition we talked about the last few months into the DB API PEP 0249: http://python.sourceforge.net/peps/pep-0249.html Feel free to adapt your database modules to these optional additions as you see fit. Also new in the spec text is a FAQ section. Questions which come up often enough will be candidates for this new spec section. One thing I'm still uncertain about is how to name the extensions in the database module docs... how about "This is an optional DB API 2.0 extension" vs. "This is a XYZ-module specific extension to the DB API 2.0". -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From chance@stsci.edu Tue Feb 5 18:25:00 2002 From: chance@stsci.edu (Don Chance) Date: Tue, 05 Feb 2002 18:25:00 +0000 Subject: [DB-SIG] what's happened to Sybase? Message-ID: <3C60237C.8040009@stsci.edu> Does anyone know what's happened to Dave Cole and his Sybase module? His web site (http://www.object-craft.com.au/projects/sybase/) is no longer functioning. Thanks, Don -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Don Chance Computer Sciences Corp. Space Telescope Science Institute 3700 San Martin Dr. Baltimore, MD 21218 410-338-4941 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From bkline@rksystems.com Tue Feb 5 23:15:56 2002 From: bkline@rksystems.com (Bob Kline) Date: Tue, 5 Feb 2002 18:15:56 -0500 (EST) Subject: [DB-SIG] what's happened to Sybase? In-Reply-To: <3C60237C.8040009@stsci.edu> Message-ID: On Tue, 5 Feb 2002, Don Chance wrote: > Does anyone know what's happened to Dave Cole and his Sybase module? > His web site (http://www.object-craft.com.au/projects/sybase/) is no > longer functioning. Last time this question was asked on the list (by me), it turned out that it came back up after a while, so you might want to just wait a while a check again later. I don't think his connection to the 'net is persistent. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com From mal@lemburg.com Wed Feb 6 09:27:44 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 06 Feb 2002 10:27:44 +0100 Subject: [DB-SIG] what's happened to Sybase? References: Message-ID: <3C60F710.9521AE0C@lemburg.com> Bob Kline wrote: > > On Tue, 5 Feb 2002, Don Chance wrote: > > > Does anyone know what's happened to Dave Cole and his Sybase module? > > His web site (http://www.object-craft.com.au/projects/sybase/) is no > > longer functioning. > > Last time this question was asked on the list (by me), it turned out > that it came back up after a while, so you might want to just wait a > while a check again later. I don't think his connection to the 'net is > persistent. FIW, the site is up again (at least I have no problem seeing the web-page). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From derry@pintunet.com Wed Feb 6 10:09:33 2002 From: derry@pintunet.com (Derry Santoso) Date: Wed, 6 Feb 2002 17:09:33 +0700 Subject: [DB-SIG] [Help] Choosing right tools for Oracle 7. Message-ID: <001301c1aef6$5fe4c2e0$3200a8c0@ainet.com> Dear All, I have problems choosing the right tools for this configuration : 1. Oracle 7.3.4 on Solaris 2.5.5 (Database Server) 2. Python 2.1.1 on HP-UX 10.20 (Client) Does anyone have any suggests for me for this case? I've tried DCOracle, but I can't get it work on HP-UX, there are so many error warning then end up with nothing. Thank You Regards, Derry Santoso From djc@object-craft.com.au Wed Feb 6 11:39:51 2002 From: djc@object-craft.com.au (Dave Cole) Date: 06 Feb 2002 22:39:51 +1100 Subject: [DB-SIG] what's happened to Sybase? In-Reply-To: <3C60F710.9521AE0C@lemburg.com> References: <3C60F710.9521AE0C@lemburg.com> Message-ID: >>>>> "M" == M -A Lemburg writes: M> Bob Kline wrote: >> >> On Tue, 5 Feb 2002, Don Chance wrote: >> >> > Does anyone know what's happened to Dave Cole and his Sybase >> module? > His web site >> (http://www.object-craft.com.au/projects/sybase/) is no > longer >> functioning. >> >> Last time this question was asked on the list (by me), it turned >> out that it came back up after a while, so you might want to just >> wait a while a check again later. I don't think his connection to >> the 'net is persistent. M> FIW, the site is up again (at least I have no problem seeing the M> web-page). We are in Australia and have to live with the unreliable DSL service provided by our monopoly telco. We use a reseller who does their best to work around the twits in the telco, but the hardware in the exchange is still at the mercy of the telco it seems. We live in the hope that the government will impose some sort of penalty on the telco for the damage they are inflicting on small businesses in this country. I am not holding my breath though. - Dave -- http://www.object-craft.com.au From jno@glasnet.ru Wed Feb 6 11:43:38 2002 From: jno@glasnet.ru (Eugene V. Dvurechenski) Date: Wed, 6 Feb 2002 14:43:38 +0300 Subject: [DB-SIG] [Help] Choosing right tools for Oracle 7. In-Reply-To: <001301c1aef6$5fe4c2e0$3200a8c0@ainet.com> References: <001301c1aef6$5fe4c2e0$3200a8c0@ainet.com> Message-ID: <20020206114338.GR19119@glas.net> --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Feb 06, 2002 at 05:09:33PM +0700, Derry Santoso wrote: > Dear All, > > I have problems choosing the right tools for this configuration : > 1. Oracle 7.3.4 on Solaris 2.5.5 (Database Server) > 2. Python 2.1.1 on HP-UX 10.20 (Client) > > Does anyone have any suggests for me for this case? > I've tried DCOracle, but I can't get it work on HP-UX, there are > so many error warning then end up with nothing. check the makefile attached - it's for Python 2.0, DCOracle 1.3.2, HP-UX B.11.00 hope, 10K attachment will not violate the rulez too much... -- 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. --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Makefile # Generated automatically from Makefile.pre by makesetup. # Generated automatically from Makefile.pre.in by sedscript. # Universal Unix Makefile for Python extensions # ============================================= # Short Instructions # ------------------ # 1. Build and install Python (1.5 or newer). # 2. "make -f Makefile.pre.in boot" # 3. "make" # You should now have a shared library. # Long Instructions # ----------------- # Build *and install* the basic Python 1.5 distribution. See the # Python README for instructions. (This version of Makefile.pre.in # only withs with Python 1.5, alpha 3 or newer.) # Create a file Setup.in for your extension. This file follows the # format of the Modules/Setup.in file; see the instructions there. # For a simple module called "spam" on file "spammodule.c", it can # contain a single line: # spam spammodule.c # You can build as many modules as you want in the same directory -- # just have a separate line for each of them in the Setup.in file. # If you want to build your extension as a shared library, insert a # line containing just the string # *shared* # at the top of your Setup.in file. # Note that the build process copies Setup.in to Setup, and then works # with Setup. It doesn't overwrite Setup when Setup.in is changed, so # while you're in the process of debugging your Setup.in file, you may # want to edit Setup instead, and copy it back to Setup.in later. # (All this is done so you can distribute your extension easily and # someone else can select the modules they actually want to build by # commenting out lines in the Setup file, without editing the # original. Editing Setup is also used to specify nonstandard # locations for include or library files.) # Copy this file (Misc/Makefile.pre.in) to the directory containing # your extension. # Run "make -f Makefile.pre.in boot". This creates Makefile # (producing Makefile.pre and sedscript as intermediate files) and # config.c, incorporating the values for sys.prefix, sys.exec_prefix # and sys.version from the installed Python binary. For this to work, # the python binary must be on your path. If this fails, try # make -f Makefile.pre.in Makefile VERSION=1.5 installdir= # where is the prefix used to install Python for installdir # (and possibly similar for exec_installdir=). # Note: "make boot" implies "make clobber" -- it assumes that when you # bootstrap you may have changed platforms so it removes all previous # output files. # If you are building your extension as a shared library (your # Setup.in file starts with *shared*), run "make" or "make sharedmods" # to build the shared library files. If you are building a statically # linked Python binary (the only solution of your platform doesn't # support shared libraries, and sometimes handy if you want to # distribute or install the resulting Python binary), run "make # python". # Note: Each time you edit Makefile.pre.in or Setup, you must run # "make Makefile" before running "make". # Hint: if you want to use VPATH, you can start in an empty # subdirectory and say (e.g.): # make -f ../Makefile.pre.in boot srcdir=.. VPATH=.. # === Bootstrap variables (edited through "make boot") === # The prefix used by "make inclinstall libainstall" of core python installdir= /usr/local # The exec_prefix used by the same exec_installdir=/usr/local # Source directory and VPATH in case you want to use VPATH. # (You will have to edit these two lines yourself -- there is no # automatic support as the Makefile is not generated by # config.status.) srcdir= . VPATH= . # === Variables that you may want to customize (rarely) === # (Static) build target TARGET= python # Installed python binary (used only by boot target) PYTHON= python # Add more -I and -D options here CFLAGS= $(OPT) -I$(INCLUDEPY) -I$(EXECINCLUDEPY) $(DEFS) # These two variables can be set in Setup to merge extensions. # See example[23]. BASELIB= BASESETUP= # === Variables set by makesetup === MODOBJS= MODLIBS= $(LOCALMODLIBS) $(BASEMODLIBS) # === Definitions added by makesetup === LOCALMODLIBS= BASEMODLIBS= -L/usr/local/lib -lreadline -ltermcap -lcrypt -lndbm -lz SHAREDMODS= oci_$(SO) Buffer$(SO) TKPATH=:lib-tk GLHACK=-Dclear=__GLclear PYTHONPATH=$(COREPYTHONPATH) COREPYTHONPATH=$(DESTPATH)$(SITEPATH)$(TESTPATH)$(MACHDEPPATH)$(TKPATH) MACHDEPPATH=:plat-$(MACHDEP) TESTPATH= SITEPATH= DESTPATH= MACHDESTLIB=$(BINLIBDEST) DESTLIB=$(LIBDEST) ORACLE_LIBS=$(ORACLE_HOME)/lib/ $(ORACLE_L) ORACLE_L=-lclntsh ORACLE_INCLUDES=$(ORACLE_HOME)/rdbms/demo \ -I$(ORACLE_HOME)/rdbms/public \ -I$(ORACLE_HOME)/network/public \ -I$(ORACLE_HOME)/plsql/public # === Variables from configure (through sedscript) === VERSION= 2.0 CC= cc -Ae LINKCC= aCC SGI_ABI= @SGI_ABI@ OPT= -O LDFLAGS= LDLAST= @LDLAST@ DEFS= -DHAVE_CONFIG_H LIBS= -lnsl -ldld LIBM= -lm LIBC= RANLIB= ranlib MACHDEP= hp-uxB SO= .sl LDSHARED= ld -b CCSHARED= +z LINKFORSHARED= -Wl,-E -Wl,+s -Wl,+b$(BINLIBDEST)/lib-dynload # Install prefix for architecture-independent files prefix= /usr/local # Install prefix for architecture-dependent files exec_prefix= ${prefix} # === Fixed definitions === # Shell used by make (some versions default to the login shell, which is bad) SHELL= /bin/sh # Expanded directories BINDIR= $(exec_installdir)/bin LIBDIR= $(exec_prefix)/lib MANDIR= $(installdir)/man INCLUDEDIR= $(installdir)/include SCRIPTDIR= $(prefix)/lib # Detailed destination directories BINLIBDEST= $(LIBDIR)/python$(VERSION) LIBDEST= $(SCRIPTDIR)/python$(VERSION) INCLUDEPY= $(INCLUDEDIR)/python$(VERSION) EXECINCLUDEPY= $(exec_installdir)/include/python$(VERSION) LIBP= $(exec_installdir)/lib/python$(VERSION) DESTSHARED= $(BINLIBDEST)/site-packages LIBPL= $(LIBP)/config PYTHONLIBS= $(LIBPL)/libpython$(VERSION).a MAKESETUP= $(LIBPL)/makesetup MAKEFILE= $(LIBPL)/Makefile CONFIGC= $(LIBPL)/config.c CONFIGCIN= $(LIBPL)/config.c.in SETUP= $(LIBPL)/Setup SYSLIBS= $(LIBM) $(LIBC) ADDOBJS= $(LIBPL)/python.o config.o # Portable install script (configure doesn't always guess right) INSTALL= $(LIBPL)/install-sh -c # Shared libraries must be installed with executable mode on some systems; # rather than figuring out exactly which, we always give them executable mode. # Also, making them read-only seems to be a good idea... INSTALL_SHARED= ${INSTALL} -m 555 # === Fixed rules === # Default target. This builds shared libraries only default: sharedmods # Build everything all: static sharedmods # Build shared libraries from our extension modules sharedmods: $(SHAREDMODS) # Build a static Python binary containing our extension modules static: $(TARGET) $(TARGET): $(ADDOBJS) lib.a $(PYTHONLIBS) Makefile $(BASELIB) $(LINKCC) $(LDFLAGS) $(LINKFORSHARED) \ $(ADDOBJS) lib.a $(PYTHONLIBS) \ $(LINKPATH) $(BASELIB) $(MODLIBS) $(LIBS) $(SYSLIBS) \ -o $(TARGET) $(LDLAST) install: sharedmods if test ! -d $(DESTSHARED) ; then \ mkdir $(DESTSHARED) ; else true ; fi -for i in X $(SHAREDMODS); do \ if test $$i != X; \ then $(INSTALL_SHARED) $$i $(DESTSHARED)/$$i; \ fi; \ done # Build the library containing our extension modules lib.a: $(MODOBJS) -rm -f lib.a ar cr lib.a $(MODOBJS) -$(RANLIB) lib.a # This runs makesetup *twice* to use the BASESETUP definition from Setup config.c Makefile: Makefile.pre Setup $(BASESETUP) $(MAKESETUP) $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) $(MAKE) -f Makefile do-it-again # Internal target to run makesetup for the second time do-it-again: $(MAKESETUP) \ -m Makefile.pre -c $(CONFIGCIN) Setup -n $(BASESETUP) $(SETUP) # Make config.o from the config.c created by makesetup config.o: config.c $(CC) $(CFLAGS) -c config.c # Setup is copied from Setup.in *only* if it doesn't yet exist Setup: cp $(srcdir)/Setup.in Setup # Make the intermediate Makefile.pre from Makefile.pre.in Makefile.pre: Makefile.pre.in sedscript sed -f sedscript $(srcdir)/Makefile.pre.in >Makefile.pre # Shortcuts to make the sed arguments on one line P=prefix E=exec_prefix H=Generated automatically from Makefile.pre.in by sedscript. L=LINKFORSHARED # Make the sed script used to create Makefile.pre from Makefile.pre.in sedscript: $(MAKEFILE) sed -n \ -e '1s/.*/1i\\/p' \ -e '2s%.*%# $H%p' \ -e '/^VERSION=/s/^VERSION=[ ]*$.*$/s%@VERSION[@]%\1%/p' \ -e '/^CC=/s/^CC=[ ]*$.*$/s%@CC[@]%\1%/p' \ -e '/^CCC=/s/^CCC=[ ]*$.*$/s%#@SET_CCC[@]%CCC=\1%/p' \ -e '/^LINKCC=/s/^LINKCC=[ ]*$.*$/s%@LINKCC[@]%\1%/p' \ -e '/^OPT=/s/^OPT=[ ]*$.*$/s%@OPT[@]%\1%/p' \ -e '/^LDFLAGS=/s/^LDFLAGS=[ ]*$.*$/s%@LDFLAGS[@]%\1%/p' \ -e '/^DEFS=/s/^DEFS=[ ]*$.*$/s%@DEFS[@]%\1%/p' \ -e '/^LIBS=/s/^LIBS=[ ]*$.*$/s%@LIBS[@]%\1%/p' \ -e '/^LIBM=/s/^LIBM=[ ]*$.*$/s%@LIBM[@]%\1%/p' \ -e '/^LIBC=/s/^LIBC=[ ]*$.*$/s%@LIBC[@]%\1%/p' \ -e '/^RANLIB=/s/^RANLIB=[ ]*$.*$/s%@RANLIB[@]%\1%/p' \ -e '/^MACHDEP=/s/^MACHDEP=[ ]*$.*$/s%@MACHDEP[@]%\1%/p' \ -e '/^SO=/s/^SO=[ ]*$.*$/s%@SO[@]%\1%/p' \ -e '/^LDSHARED=/s/^LDSHARED=[ ]*$.*$/s%@LDSHARED[@]%\1%/p' \ -e '/^CCSHARED=/s/^CCSHARED=[ ]*$.*$/s%@CCSHARED[@]%\1%/p' \ -e '/^$L=/s/^$L=[ ]*$.*$/s%@$L[@]%\1%/p' \ -e '/^$P=/s/^$P=$.*$/s%^$P=.*%$P=\1%/p' \ -e '/^$E=/s/^$E=$.*$/s%^$E=.*%$E=\1%/p' \ $(MAKEFILE) >sedscript echo "/^#@SET_CCC@/d" >>sedscript echo "/^installdir=/s%=.*%= $(installdir)%" >>sedscript echo "/^exec_installdir=/s%=.*%=$(exec_installdir)%" >>sedscript echo "/^srcdir=/s%=.*%= $(srcdir)%" >>sedscript echo "/^VPATH=/s%=.*%= $(VPATH)%" >>sedscript echo "/^LINKPATH=/s%=.*%= $(LINKPATH)%" >>sedscript echo "/^BASELIB=/s%=.*%= $(BASELIB)%" >>sedscript echo "/^BASESETUP=/s%=.*%= $(BASESETUP)%" >>sedscript # Bootstrap target boot: clobber VERSION=`$(PYTHON) -c "import sys; print sys.version[:3]"`; \ installdir=`$(PYTHON) -c "import sys; print sys.prefix"`; \ exec_installdir=`$(PYTHON) -c "import sys; print sys.exec_prefix"`; \ $(MAKE) -f $(srcdir)/Makefile.pre.in VPATH=$(VPATH) srcdir=$(srcdir) \ VERSION=$$VERSION \ installdir=$$installdir \ exec_installdir=$$exec_installdir \ Makefile # Handy target to remove intermediate files and backups clean: -rm -f *.o *~ # Handy target to remove everything that is easily regenerated clobber: clean -rm -f *.a tags TAGS config.c Makefile.pre $(TARGET) sedscript -rm -f *.so *.sl so_locations # Handy target to remove everything you don't want to distribute distclean: clobber -rm -f Makefile Setup # Rules appended by makedepend oci_.o: $(srcdir)/oci_.c; $(CC) $(CCSHARED) -I$(ORACLE_INCLUDES) -DDCORACLE8 $(CFLAGS) -c $(srcdir)/oci_.c oci_$(SO): oci_.o; $(LDSHARED) oci_.o /usr/lib/libpthread.a -L$(ORACLE_LIBS) -o oci_$(SO) Buffer.o: $(srcdir)/Buffer.c; $(CC) $(CCSHARED) $(CFLAGS) -c $(srcdir)/Buffer.c Buffer$(SO): Buffer.o; $(LDSHARED) Buffer.o -o Buffer$(SO) --/NkBOFFp2J2Af1nK-- From derry@pintunet.com Wed Feb 6 12:11:50 2002 From: derry@pintunet.com (Derry Santoso) Date: Wed, 6 Feb 2002 19:11:50 +0700 Subject: [DB-SIG] [Help] Choosing right tools for Oracle 7. References: <001301c1aef6$5fe4c2e0$3200a8c0@ainet.com> <20020206114338.GR19119@glas.net> Message-ID: <005901c1af07$765ca720$3200a8c0@ainet.com> > check the makefile attached - it's for Python 2.0, > DCOracle 1.3.2, HP-UX B.11.00 Can you tell me what should I do with this Makefile? Thx! Derry S. From matt@zope.com Wed Feb 6 13:09:33 2002 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 6 Feb 2002 08:09:33 -0500 Subject: [DB-SIG] [Help] Choosing right tools for Oracle 7. References: <001301c1aef6$5fe4c2e0$3200a8c0@ainet.com> Message-ID: <003f01c1af0f$8613cf60$0501010a@mi.org> Derry, Try DCOracle2 with updated Oracle Client libs -- ie Oracle 8+ client libs. You should still be able to connect to a version 7 database. HP/UX is just "different enough" that I can't give you the proper instructions off the top of my head (and I have no access to an HP/UX system) to tell you want you need to to do build the OCI 7 based DCOracle. ----- Original Message ----- From: "Derry Santoso" To: Sent: Wednesday, February 06, 2002 5:09 AM Subject: [DB-SIG] [Help] Choosing right tools for Oracle 7. > Dear All, > > I have problems choosing the right tools for this configuration : > 1. Oracle 7.3.4 on Solaris 2.5.5 (Database Server) > 2. Python 2.1.1 on HP-UX 10.20 (Client) > > Does anyone have any suggests for me for this case? > I've tried DCOracle, but I can't get it work on HP-UX, there are > so many error warning then end up with nothing. > > Thank You > > Regards, > Derry Santoso > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From derry@pintunet.com Wed Feb 6 18:16:20 2002 From: derry@pintunet.com (Derry Santoso) Date: Thu, 7 Feb 2002 01:16:20 +0700 Subject: [DB-SIG] [Help] Choosing right tools for Oracle 7. References: <001301c1aef6$5fe4c2e0$3200a8c0@ainet.com> <20020206114338.GR19119@glas.net> <003901c1af06$ae01c260$3200a8c0@ainet.com> <20020206131733.GS19119@glas.net> Message-ID: <005e01c1af3a$62014960$3200a8c0@ainet.com> Hi, I still can't make the modules. After making minor modification which suit to the system, this error came up: # make [----cut!----] ld -b oci_.o /usr/lib/libpthread.a -L/opt/app/oracle/product/7.3.4/lib/libclntsh.sl -o oci_.sl ld: Can't open /usr/lib/libpthread.a ld: No such file or directory *** Error exit code 1 Stop. I already search for 'libpthread.a', but I can't found it anywhere on the system. What should I do now? FYI, I also tried another way, which is, following exactly what the docs said : - Copy Setup-7.3.2 to Setup - Copy Makefile.pre.in-1.5 to Makefile.pre.in - make -f Makefile.pre.in boot - make .. And all end up with Buffer.sl and oci_.sl successfully created. Then i tried to use those modules : >>> import Buffer, oci_, sys >>> db=oci_.Connect('user/passwd@sid') /usr/lib/dld.sl: Unresolved symbol: pthread_mutexattr_default (data) from oci_.sl /usr/lib/dld.sl: Unresolved symbol: pthread_attr_default (data) from oci_.sl /usr/lib/dld.sl: Unresolved module for symbol: sltsrsa (code) from oci_.sl Abort(coredump) # *sigh* .. well, i know it would happen, may be it just work well on python-1.5. :-( Another suggestion? Best Regards, Derry Santoso ----- Original Message ----- From: "Eugene V. Dvurechenski" To: "Derry Santoso" Sent: Wednesday, February 06, 2002 8:17 PM Subject: Re: [DB-SIG] [Help] Choosing right tools for Oracle 7. > for the first time, just try to put it into DCOracle/src/ dir > and make it. > > well, you may need to fix ORACLE_HOME (and drived) dirs in the file. > > in general, the most problem is to locate proper libs and include them > proper number of times into the ld command line. > > yep, it sounds odd, but oracle libs often need to be incuded more than > once just because of cross refs... > > On Wed, Feb 06, 2002 at 07:06:11PM +0700, Derry Santoso wrote: > > > check the makefile attached - it's for Python 2.0, > > > DCOracle 1.3.2, HP-UX B.11.00 > > > > Can you tell me what should I do with this Makefile? > > > > Thx! > > > > > > Derry S. > > > > -- > 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 matt@zope.com Wed Feb 6 18:56:53 2002 From: matt@zope.com (Matthew T. Kromer) Date: Wed, 06 Feb 2002 13:56:53 -0500 Subject: [DB-SIG] [Help] Choosing right tools for Oracle 7. References: <001301c1aef6$5fe4c2e0$3200a8c0@ainet.com> <20020206114338.GR19119@glas.net> <003901c1af06$ae01c260$3200a8c0@ainet.com> <20020206131733.GS19119@glas.net> <005e01c1af3a$62014960$3200a8c0@ainet.com> Message-ID: <3C617C75.1000901@zope.com> Derry Santoso wrote: >Hi, > >I still can't make the modules. After making minor modification which >suit to the system, this error came up: > ># make >[----cut!----] > ld -b oci_.o > /usr/lib/libpthread.a -L/opt/app/oracle/product/7.3.4/lib/libclntsh.sl -o >oci_.sl >ld: Can't open /usr/lib/libpthread.a >ld: No such file or directory >*** Error exit code 1 > >Stop. > >I already search for 'libpthread.a', but I can't found it anywhere on the >system. >What should I do now? > You're going to have to have the pthreads library for HP/UX installed. This *may* be part of the DCE package for HP/UX, but the only way I know to get H to puke is to stick my finger down its throat. The second set of error messages you received detail the fact that the pthreads libraries are necessary. You can *try* scanning the libraries you have with "nm" to find the symbols necessary, and substituting that library name for -lpthread -- but I can't be more specific. I tend to use things like cd /usr/lib for b in *.a *.so; do nm $b | grep pthread_attr && echo $b done to help find these symbols. Typically you'll want to see a "T" symbol (text) next to a reference, rather than a "W" or "U" or other such symbols (for weak refs and regular refs). I strongly suggest spending some time surfing Google to find what relevant patches and/or packages you may need to apply to HP/UX 10.20 to let you compile Oracle applications on it. Hopefully some one else here on DB-SIG has enough experience on HP boxen to enlighten you with specific details on what you need to do. -- Matt Kromer Zope Corporation http://www.zope.com/ From djc@object-craft.com.au Sat Feb 9 13:40:32 2002 From: djc@object-craft.com.au (Dave Cole) Date: 10 Feb 2002 00:40:32 +1100 Subject: [DB-SIG] Sybase module 0.33pre2 released In-Reply-To: Message-ID: What is it: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. WARNING: Since the last release I have come to the realisation that the Sybase dynamic SQL functionality is not nearly general enough to use for correct DB-API functionality. I have thrown up my hands and gone back to the drawing board with the high level Sybase.py module. Once the module is stable again there will be three differences between the new and old functionality: 1) The paramstyle is now 'format'. This means that where you previously did something like this: c.execute("select * from titles where title like ?", ['The %']) you now have to do this: c.execute("select * from titles where title like '%s'", ['The %']) or this: c.execute("select * from titles where title like 'The %'") 2) Since the cursors are no longer using dynamic SQL there will no longer be an extra result set which reported the status of the temporary stored procedure. This should remove some of the confusion behaviour of cursors. There should be fewer restrictions on the use of cursors. 3) Threading is enabled in the CT library wrapper by default. PLEADING: Please download the pre-release version, try it out, and then send me some mail telling me what you found. You would be surprised at how little mail I get regarding the Sybase module, I really do need your help. The module is available here: http://www.object-craft.com.au/projects/sybase/sybase-0.33pre2.tar.gz The module home page is here: http://www.object-craft.com.au/projects/sybase/ - Dave -- http://www.object-craft.com.au From arthuralbano@hotmail.com Sat Feb 9 17:17:47 2002 From: arthuralbano@hotmail.com (Arthur Albano) Date: Sun, 10 Feb 2002 02:17:47 +0900 Subject: [DB-SIG] Generic qustion about a particular (singular?) DB... Message-ID: Hi Folks, I'm a newbie around and I was wondering about a hand-made Python + CGI + Native XML Relational IMDB. What do you think about the idea? Arthur Albano (Weekend Programmer) _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From magnus@thinkware.se Sun Feb 10 23:24:44 2002 From: magnus@thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Mon, 11 Feb 2002 00:24:44 +0100 Subject: [DB-SIG] Sybase module 0.33pre2 released In-Reply-To: References: Message-ID: <5.1.0.14.0.20020210203505.04051630@mail.irrblosset.se> At 00:40 2002-02-10 +1100, Dave Cole wrote: >Since the last release I have come to the realisation that the Sybase >dynamic SQL functionality is not nearly general enough to use for >correct DB-API functionality. Really? Is this due to some kind of deviation from standards in Sybase, or is the DB-API making assumptions about behaviour which we can't really expect the database vendors to live up to? --=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 djc@object-craft.com.au Mon Feb 11 11:31:02 2002 From: djc@object-craft.com.au (Dave Cole) Date: 11 Feb 2002 22:31:02 +1100 Subject: [DB-SIG] Sybase module 0.33pre2 released In-Reply-To: <5.1.0.14.0.20020210203505.04051630@mail.irrblosset.se> References: <5.1.0.14.0.20020210203505.04051630@mail.irrblosset.se> Message-ID: >>>>> "Magnus" =3D=3D Magnus Lyck=E5 writes: Magnus> At 00:40 2002-02-10 +1100, Dave Cole wrote: >> Since the last release I have come to the realisation that the >> Sybase dynamic SQL functionality is not nearly general enough to >> use for correct DB-API functionality. Magnus> Really? Is this due to some kind of deviation from standards Magnus> in Sybase, or is the DB-API making assumptions about behaviour Magnus> which we can't really expect the database vendors to live up Magnus> to? The problem is caused by the way that Sybase handles dynamic SQL. When you use the ct_dynamic() CT library function the server creates a temporary stored procedure. The advantage to this is that the SQL is compiled once at the server and can then accept parameters via the ct_param() function. This allows the module to send parameters in binary form. When I read about the above I decided that it was an excellent fit for the DB-API since the specification talks about the Cursor.execute() method compiling the SQL once and then accepting further arguments to the same expression without penalty. For most cases this is true. Unfortunately for me, I missed the small print about the limitations on the type of argument which can be sent to a stored procedure. You cannot send TEXT or IMAGE parameters to stored procedures :-(. - Dave --=20 http://www.object-craft.com.au From jacobs@penguin.theopalgroup.com Tue Feb 12 15:11:11 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Tue, 12 Feb 2002 10:11:11 -0500 (EST) Subject: [DB-SIG] RFC: Higher level DB-API objects Message-ID: Hello everyone, As many of you have already heard at the Python-10 conference, my company has implemented a very comprehensive set of extensions on top of the DB-API interface. We plan to contribute much of this to the Python community in the form of an Open Source (tm) project. However, there are a great many issues involved in taking a proprietary set of extensions and making them palatable to general audiences. So I thought I would start the discussions in the Python DB-SIG, since many of the DB-API module implementers are likely to hang out here. My goal is not to make the existing DB-API objects fatter. They're pretty much the right size already. On the other hand, I have not ruled out proposing such changes, provided they make sense for the community at large and will be supported by DB-module authors. That said, you're probably wondering what I have in mind. I'll start by explaining what we've already developed for our own in-house use. For the past three years, I've been working on a database abstraction framework I (imaginatively) call DBLIB. It abstracts a great deal about various database backends into a single programatic interface. The major features are: 1) A complete SQL92 parser and dialect processor that can translate many queries and SQL expressions from one SQL dialect to another. Currently supported are some basic translations between o Oracle o MySQL o PostgreSQL o Microsoft SQL-Server 2000 o SAPDB (plus a few others) NB: This is more of a framework than a complete working product. It translates what we have needed for our past projects, and there are a huge number of additional transformations possible. This component is a classic candidate for being turned into an Open Source project, since many contributors will significantly enhance its usefulness. 2) A distributed transaction manager framework. The goal of this component is to provide reliable logging of transactions that occur over multiple non-atomic operations over multiple backends. This logging makes it possible to detect and possibly apply user-specified functionality to recover from failed (i.e., partially committed) distributed transactions. 3) A connection management and abstraction layer on top of DB-API objects to map DSN strings to backend driver instances, with intelligent support for various connection pooling methods. 4) A new DB-API abstraction object that hooks into the connection manager, the distributed transaction manager, and the SQL parser and dialect translator that allows extremely backend-neutral code to be written. e.g., you can write Python code that works with MS-SQL, PostgreSQL, MySQL, Oracle, etc. with virtually no modifications. Changing from one backend to another is simply a matter of adjusting the DSN string to select another driver. 5) Meta-query objects: query algebra objects that allow programatic manipulation of queries. These objects support all of the usual relational-algebraic operations, and can flatten themselves into SQL with nested-subqueries or a sequence of SQL statements using temporary tables (to work around backends that cannot perform sub-selects). 6) A query processor and optimizer, in some ways very much like Gadfly. Its major use is to take queries that join multiple tables from multiple disjoint backends and perform the query in a distributed fashion. This involves factoring SQL queries into blocks that can be executed in parallel on multiple backends, and then aggregating the results and remaining query operations. The result set produced is as if it were run on a single relational query backend. These and other components are currently implemented in Python and are used in several very large business applications for several >$100M companies. Some of the code for the above features cannot be released, some cannot be released in its current form, some can easily be exported and be useful immediately. I _could_ get out the ole' chainsaw and gut the portions of our code base that I am free to release. However, I'm not sure of the utility of handing out disjointed, incomplete and proprietary sets of functions and objects. Rather, I'd like to start discussions on how to make this code, or at least the ideas embodied by it, accessible to the general Python community. I welcome any help that the members of this SIG have to offer and look forward to the ensuing discussions. Eventually, I'd like to find a core group of developers to help write a comprehensive and unified high-level database library and business object interfaces that will significantly enhance Python's ability to compete with other languages and technologies. I welcome any comments and suggestions, and will be happy to go into more detail on some of the issues I have raised. Best 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 fog@debian.org Tue Feb 12 15:40:59 2002 From: fog@debian.org (Federico Di Gregorio) Date: 12 Feb 2002 16:40:59 +0100 Subject: [DB-SIG] RFC: Higher level DB-API objects In-Reply-To: References: Message-ID: <1013528459.869.33.camel@nenya> --=-IKDIEyJqv0AfVeIFR+Vi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Il mar, 2002-02-12 alle 16:11, Kevin Jacobs ha scritto: [very interesting stuff snipped] > These and other components are currently implemented in Python and are us= ed > in several very large business applications for several >$100M companies. > Some of the code for the above features cannot be released, some cannot b= e > released in its current form, some can easily be exported and be useful > immediately. I _could_ get out the ole' chainsaw and gut the portions of > our code base that I am free to release. However, I'm not sure of the > utility of handing out disjointed, incomplete and proprietary sets of > functions and objects. >=20 > Rather, I'd like to start discussions on how to make this code, or at lea= st > the ideas embodied by it, accessible to the general Python community. I > welcome any help that the members of this SIG have to offer and look forw= ard > to the ensuing discussions. Eventually, I'd like to find a core group of > developers to help write a comprehensive and unified high-level database > library and business object interfaces that will significantly enhance > Python's ability to compete with other languages and technologies. i think the better thing is tring to get the best of both worlds. first of all start the chainsaw and make available the code under a free (open) license. nothing convoluted or half-free, just choose what you like better (GPL, X11, BSD, ZPL, MPL) and release. this is very important to solve the chiken-and-egg problem: until there is no code it is very difficult to find developers and without developers is quite hard to build a group working on the code. then start working on some pieces of the code and start a discussion on how to do it here or on some other mailing list dedicated to the argument. but do that after releasing the code. almost 90% of the people i know just get bored after a couple of email if don't have bits to work on. you can just say "i have that code that does such and such and misses such and such, what about it?" i am sure you'll get a lot of ideas and patches. hope this helps, federico --=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 --=-IKDIEyJqv0AfVeIFR+Vi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Per informazioni si veda http://www.gnupg.org iEYEABECAAYFAjxpN4sACgkQvcCgrgZGjeuzMQCeKzJLpR1t1XNOG+N6YZc+pmaW GdEAoIfApAk9MGdwci2VMc9hjMbDecpf =MqZq -----END PGP SIGNATURE----- --=-IKDIEyJqv0AfVeIFR+Vi-- From jacobs@penguin.theopalgroup.com Tue Feb 12 15:47:23 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Tue, 12 Feb 2002 10:47:23 -0500 (EST) Subject: [DB-SIG] RFC: Higher level DB-API objects In-Reply-To: <1013528459.869.33.camel@nenya> Message-ID: On 12 Feb 2002, Federico Di Gregorio wrote: > i think the better thing is tring to get the best of both worlds. first > of all start the chainsaw and make available the code under a free > (open) license. nothing convoluted or half-free, just choose what you > like better (GPL, X11, BSD, ZPL, MPL) and release. > > this is very important to solve the chiken-and-egg problem: until there > is no code it is very difficult to find developers and without > developers is quite hard to build a group working on the code. I'm sorry I didn't make this clearer. I do intend to start releasing code fairly soon -- though only a chunk at a time. For example, my initial plan is to release my SQL92 parser, meta-query objects, and a few low level widgets first. They're fairly easy to factor out and work on without banging our heads on tricky standarization issues. I am still working with our lawyers on the exact license to use, and hope to have something concrete within the week. Thanks, -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 dennis@lercnetworks.com Tue Feb 12 18:34:52 2002 From: dennis@lercnetworks.com (Dennis Sacks) Date: Tue, 12 Feb 2002 11:34:52 -0700 (MST) Subject: [DB-SIG] create database in Python Database API 2.0 Message-ID: Hi, I want to execute something like "create database" from python, yet I cannot do it with a cursor.execute. What is the mechanism for executing nontransaction oriented commands like that? Dennis From pshafaee@hostway.com Tue Feb 12 18:39:58 2002 From: pshafaee@hostway.com (John Shafaee) Date: Tue, 12 Feb 2002 12:39:58 -0600 Subject: [DB-SIG] Re: DB-SIG digest, Vol 1 #564 - 3 msgs References: Message-ID: <3C69617E.94301B41@hostway.net> This idea is right in -line with several proposals that have come across the mailing list in the past year or so. I am all for it. We at Hostway have come up with a similar architecture for generalizing database operations. I think there will be a huge motivation for such an application if more people learn of the ideas that you have touched on. I agree that the base code that you have should make a good (and possibly essential) starting point. --john s. Hostway db-sig-request@python.org wrote: > Send DB-SIG mailing list submissions to > db-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/db-sig > or, via email, send a message with subject or body 'help' to > db-sig-request@python.org > > You can reach the person managing the list at > db-sig-admin@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DB-SIG digest..." > > ------------------------------------------------------------------------ > Today's Topics: > > 1. RFC: Higher level DB-API objects (Kevin Jacobs) > 2. Re: RFC: Higher level DB-API objects (Federico Di Gregorio) > 3. Re: RFC: Higher level DB-API objects (Kevin Jacobs) > > ------------------------------------------------------------------------ > > Subject: [DB-SIG] RFC: Higher level DB-API objects > Date: Tue, 12 Feb 2002 10:11:11 -0500 (EST) > From: Kevin Jacobs > To: > > Hello everyone, > > As many of you have already heard at the Python-10 conference, my company > has implemented a very comprehensive set of extensions on top of the DB-API > interface. We plan to contribute much of this to the Python community in > the form of an Open Source (tm) project. However, there are a great many > issues involved in taking a proprietary set of extensions and making them > palatable to general audiences. So I thought I would start the discussions > in the Python DB-SIG, since many of the DB-API module implementers are > likely to hang out here. > > My goal is not to make the existing DB-API objects fatter. They're > pretty much the right size already. On the other hand, I have not ruled out > proposing such changes, provided they make sense for the community at large > and will be supported by DB-module authors. > > That said, you're probably wondering what I have in mind. I'll start by > explaining what we've already developed for our own in-house use. > > For the past three years, I've been working on a database abstraction > framework I (imaginatively) call DBLIB. It abstracts a great deal about > various database backends into a single programatic interface. The major > features are: > > 1) A complete SQL92 parser and dialect processor that can translate many > queries and SQL expressions from one SQL dialect to another. > Currently supported are some basic translations between > o Oracle > o MySQL > o PostgreSQL > o Microsoft SQL-Server 2000 > o SAPDB > (plus a few others) > > NB: This is more of a framework than a complete working product. It > translates what we have needed for our past projects, and there are > a huge number of additional transformations possible. This > component is a classic candidate for being turned into an Open > Source project, since many contributors will significantly enhance > its usefulness. > > 2) A distributed transaction manager framework. The goal of this > component is to provide reliable logging of transactions that occur > over multiple non-atomic operations over multiple backends. This > logging makes it possible to detect and possibly apply user-specified > functionality to recover from failed (i.e., partially committed) distributed > transactions. > > 3) A connection management and abstraction layer on top of DB-API objects > to map DSN strings to backend driver instances, with intelligent > support for various connection pooling methods. > > 4) A new DB-API abstraction object that hooks into the connection manager, > the distributed transaction manager, and the SQL parser and dialect > translator that allows extremely backend-neutral code to be written. > e.g., you can write Python code that works with MS-SQL, PostgreSQL, > MySQL, Oracle, etc. with virtually no modifications. Changing from one > backend to another is simply a matter of adjusting the DSN string to > select another driver. > > 5) Meta-query objects: query algebra objects that allow programatic > manipulation of queries. These objects support all of the usual > relational-algebraic operations, and can flatten themselves into > SQL with nested-subqueries or a sequence of SQL statements using > temporary tables (to work around backends that cannot perform > sub-selects). > > 6) A query processor and optimizer, in some ways very much like Gadfly. > Its major use is to take queries that join multiple tables from > multiple disjoint backends and perform the query in a distributed > fashion. This involves factoring SQL queries into blocks that can be > executed in parallel on multiple backends, and then aggregating the > results and remaining query operations. The result set produced is as > if it were run on a single relational query backend. > > These and other components are currently implemented in Python and are used > in several very large business applications for several >$100M companies. > Some of the code for the above features cannot be released, some cannot be > released in its current form, some can easily be exported and be useful > immediately. I _could_ get out the ole' chainsaw and gut the portions of > our code base that I am free to release. However, I'm not sure of the > utility of handing out disjointed, incomplete and proprietary sets of > functions and objects. > > Rather, I'd like to start discussions on how to make this code, or at least > the ideas embodied by it, accessible to the general Python community. I > welcome any help that the members of this SIG have to offer and look forward > to the ensuing discussions. Eventually, I'd like to find a core group of > developers to help write a comprehensive and unified high-level database > library and business object interfaces that will significantly enhance > Python's ability to compete with other languages and technologies. > > I welcome any comments and suggestions, and will be happy to go into more > detail on some of the issues I have raised. > > Best 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 > > ------------------------------------------------------------------------ > > Subject: Re: [DB-SIG] RFC: Higher level DB-API objects > Date: 12 Feb 2002 16:40:59 +0100 > From: Federico Di Gregorio > To: Python DB-SIG Mailing List > References: > > Il mar, 2002-02-12 alle 16:11, Kevin Jacobs ha scritto: > [very interesting stuff snipped] > > These and other components are currently implemented in Python and are used > > in several very large business applications for several >$100M companies. > > Some of the code for the above features cannot be released, some cannot be > > released in its current form, some can easily be exported and be useful > > immediately. I _could_ get out the ole' chainsaw and gut the portions of > > our code base that I am free to release. However, I'm not sure of the > > utility of handing out disjointed, incomplete and proprietary sets of > > functions and objects. > > > > Rather, I'd like to start discussions on how to make this code, or at least > > the ideas embodied by it, accessible to the general Python community. I > > welcome any help that the members of this SIG have to offer and look forward > > to the ensuing discussions. Eventually, I'd like to find a core group of > > developers to help write a comprehensive and unified high-level database > > library and business object interfaces that will significantly enhance > > Python's ability to compete with other languages and technologies. > > i think the better thing is tring to get the best of both worlds. first > of all start the chainsaw and make available the code under a free > (open) license. nothing convoluted or half-free, just choose what you > like better (GPL, X11, BSD, ZPL, MPL) and release. > > this is very important to solve the chiken-and-egg problem: until there > is no code it is very difficult to find developers and without > developers is quite hard to build a group working on the code. > > then start working on some pieces of the code and start a discussion on > how to do it here or on some other mailing list dedicated to the > argument. but do that after releasing the code. almost 90% of the people > i know just get bored after a couple of email if don't have bits to work > on. you can just say "i have that code that does such and such and > misses such and such, what about it?" i am sure you'll get a lot of > ideas and patches. > > hope this helps, > federico > > -- > 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; � stato tristissimo, perch� mi ha succhiato un pezzo di > anima. -- Alessandro Rubini > > ------------------------------------------------------------------------ > Part 1.3.2.1.2Type: application/pgp-signature > > ------------------------------------------------------------------------ > > Subject: Re: [DB-SIG] RFC: Higher level DB-API objects > Date: Tue, 12 Feb 2002 10:47:23 -0500 (EST) > From: Kevin Jacobs > To: Federico Di Gregorio > CC: Python DB-SIG Mailing List > > On 12 Feb 2002, Federico Di Gregorio wrote: > > i think the better thing is tring to get the best of both worlds. first > > of all start the chainsaw and make available the code under a free > > (open) license. nothing convoluted or half-free, just choose what you > > like better (GPL, X11, BSD, ZPL, MPL) and release. > > > > this is very important to solve the chiken-and-egg problem: until there > > is no code it is very difficult to find developers and without > > developers is quite hard to build a group working on the code. > > I'm sorry I didn't make this clearer. I do intend to start releasing code > fairly soon -- though only a chunk at a time. For example, my initial plan > is to release my SQL92 parser, meta-query objects, and a few low level > widgets first. They're fairly easy to factor out and work on without > banging our heads on tricky standarization issues. I am still working with > our lawyers on the exact license to use, and hope to have something concrete > within the week. > > Thanks, > -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 Tue Feb 12 19:17:50 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Tue, 12 Feb 2002 14:17:50 -0500 (EST) Subject: [DB-SIG] create database in Python Database API 2.0 In-Reply-To: Message-ID: On Tue, 12 Feb 2002, Dennis Sacks wrote: > I want to execute something like "create database" from python, yet I > cannot do it with a cursor.execute. What is the mechanism for executing > nontransaction oriented commands like that? 'create database' is one of those commands that some drivers cannot execute at all. What backend and driver are you having trouble with? Also, most cursors can run commands like 'create/drop/alter table/index/view/etc'. -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 python.db-sig@maz.nu Tue Feb 12 21:31:05 2002 From: python.db-sig@maz.nu (Marek Isalski) Date: Tue, 12 Feb 2002 21:31:05 +0000 Subject: [DB-SIG] create database in Python Database API 2.0 In-Reply-To: References:

Message-ID: <20020212213105.GE1203@fataltragedy.faelix.org> --ep0oHQY+/Gbo/zt0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kevin Jacobs [jacobs@penguin.theopalgroup.com] wrote: > On Tue, 12 Feb 2002, Dennis Sacks wrote: > > I want to execute something like "create database" from python, yet I > > cannot do it with a cursor.execute. What is the mechanism for executing > > nontransaction oriented commands like that? > > 'create database' is one of those commands that some drivers cannot execu= te > at all. What backend and driver are you having trouble with? Also, most > cursors can run commands like 'create/drop/alter table/index/view/etc'. Speaking for KInterbasDB (Firebird/Interbase bindings that I'm involved in), we've provided an execute_immediate() function in the module which gets around this problem. It's a bit of a kludge, I admit... Should it really matter that some drivers cannot execute this command? After all, the DB-API specifies rollback() as optional. Perhaps a formal specification of a function like execute_immediate() could help here? Optional for backends that support it. --=20 Maz I'm going stir-crazy, and I've joined the ranks of the walking brain- dead, but otherwise I'm just peachy. -- Lyta Hall on parenthood, in SANDMAN #40: "Parliament of Rooks" --ep0oHQY+/Gbo/zt0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aYmZbTAIQacXP+URAlC8AKCnZrhHAzXyVrv/0LuCvRjHuKqA9QCfeF/5 6d/IWNItcmrY40DuEo0iHzQ= =ibia -----END PGP SIGNATURE----- --ep0oHQY+/Gbo/zt0-- From jacobs@penguin.theopalgroup.com Tue Feb 12 21:39:34 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Tue, 12 Feb 2002 16:39:34 -0500 (EST) Subject: [DB-SIG] Our first contribution: a row class In-Reply-To: Message-ID: Here is my first code contribution and discussion-piece. It can be downloaded from: http://opensource.theopalgroup.com/ I've thrown together a very simple starting page, that will hopefully turn into a fairly nice hub of Python activity. ---------------------------------------------------------------------------- Here is a description from the db_row.py module: This module defines light-weight objects suitable for many applications, though the primary goal of the implementer is for storage of database query results. The primary design criteria for the data-structure where: 1) store a sequence of arbitrary Python objects 2) the number of items stored in each instance should be constant 3) each instance must be as light-weight as possible, since many thousands of them could be created 4) values must be retrievable by index e.g.: d[3] 5) values must be retrievable by a field name using the Python attribute syntax: e.g.: d.field 6) values must be retrievable by a field name using the Python item syntax: e.g.: d['field'] 7) optionally, operations using field names should be case-insensitive e.g.: d['FiElD'] 8) should support standard list and dictionary -like interfaces, including slicing 9) should be convertible to a list, tuple or dictionary These criteria are chosen to simplify access to rows that are returned from database queries. Lets say that you run this query: cursor.execute('SELECT a,b,c FROM blah;') results = cursor.fetchall() The resulting data-structure is typically a list if row tuples. e.g.: results = [ (1,2,3), (3,4,5), (6,7,8) ] While entirely functional, these data types only allow integer indexed access. e.g., to query the 'b' attribute of the second row: b = results[1][1] This requires that all query results are accessed by index, which can be very tedious and the code using this technique tends to be hard to maintain. The alternative has always been to return a list of native Python dictionaries, one for each row. e.g.: results = [ {'a':1,'b':2,'c':3}, {'a':3,'b':4,'c':5}, {'a':6,'b':7,'c':8} ] This has the advantage of easier access to attributes by name, e.g.: b = results[1]['b'] There are several serious disadvantages: 1) each row requires a heavy-weight dictionary _per instance_. This can damage performance when returning, say, 100,000 rows from a query. 2) access by index is lost since Python dictionaries are unordered. 3) attribute-access syntax is somewhat sub-optimal (or at least inflexible) since it must use the item-access syntax. i.e., x['a'] vs. x.a. The second and third problems can be addressed by creating a subclass of UserDict (a Python class that looks and acts like a dictionary), though that only magnifies the performance problems. HOWEVER, there are some new features in Python 2.2 that can provide the best of all possible worlds. Here is an example: # Create a new class type to store the results from our query # (we'll make field names case-insensitive just to show off) > R=make_row_class(['a','b','c'], insensitive = 1) # Create an instance of our new tuple class with values 1,2,3 > r=R( (1,2,3) ) # Demonstrate all three accessor types > print r['a'], r[1], r.c 1 2 3 # Demonstrate all case-insensitive operation > print r['a'], r['A'] 1 1 # Return the keys (column names) > print r.keys() ('a', 'b', 'c') # Return the values > print r.values() [1, 2, 3] # Return a list of keys and values > print r.items() [('a', 1), ('b', 2), ('c', 3)] # Return a dictionary of the keys and values > print r.dict() {'a': 1, 'c': 3, 'b': 2} # Demonstrate slicing behavior > print r[1:3] [2, 3] This solution uses some new Python 2.2 features and ends up allocating only one dictionary _per row class__, not per row instance. i.e., the row instances do not allocate a dictionary at all! This is accomplished using the new-style object 'slots' mechanism. Here is how you could use these objects: cursor.execute('SELECT a,b,c FROM blah;') # Build the field list from the field names returned by the query fields = [ d[0] for d in cursor.description ] # Make a class to store the resulting rows R = make_row_class(fields, insensitive = 1) # Build the rows from the row class and each tuple returned from the cursor results = [ R(row) for row in cursor.fetchall() ] print results[1].b, results[2].B, results[3]['b'], results[2][1] Open implementation issues: o This implementation will likely break when Python 2.3 comes out, since super will become a keyword and possibly due to other syntactic changes. The code will be trivial to fix, so this is not a big concern. o Values are currently mutable. This opens the door to several problems: 1) .items(), .values() and .keys() do not skip slots that do not have values assigned. This is so that the field indices will always be consistent. Instead, they will represent missing values with 'None' objects. e.g.: > R=make_row_class(['a','b','c'], insensitive = 1) > r=R([1,2,3]) > print r.items() [('a', 1), ('b', 2), ('c', 3)] > del r[:] > print r.items() [('a', None), ('b', None), ('c', None)] 2) Row equality and hashing are open issues. I do not intend to compare rows or store them in dictionaries, so this does not bother me much. Others may want to, so maybe it is desirable to have a mutable and immutable instance types. o The current code is a little schitzophrenic about returning lists and tuples. Some operations return one, some the other. We should pick one way and stick to it. o More doc-strings are needed, including dynamic row class doc-strings o Add integrated unit-tests (a la doctest, most likely) o Maybe some better example code -- 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@debian.org Wed Feb 13 00:37:29 2002 From: fog@debian.org (Federico Di Gregorio) Date: 13 Feb 2002 01:37:29 +0100 Subject: [DB-SIG] create database in Python Database API 2.0 In-Reply-To: <20020212213105.GE1203@fataltragedy.faelix.org> References:

<20020212213105.GE1203@fataltragedy.faelix.org> Message-ID: <1013560650.2521.0.camel@nenya> --=-qEP0Anzi+tzjkzdzjR8b Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il mar, 2002-02-12 alle 22:31, Marek Isalski ha scritto: > Kevin Jacobs [jacobs@penguin.theopalgroup.com] wrote: > > On Tue, 12 Feb 2002, Dennis Sacks wrote: > > > I want to execute something like "create database" from python, yet I > > > cannot do it with a cursor.execute. What is the mechanism for executi= ng > > > nontransaction oriented commands like that? > > > > 'create database' is one of those commands that some drivers cannot exe= cute > > at all. What backend and driver are you having trouble with? Also, mo= st > > cursors can run commands like 'create/drop/alter table/index/view/etc'. >=20 > Speaking for KInterbasDB (Firebird/Interbase bindings that I'm involved > in), we've provided an execute_immediate() function in the module which > gets around this problem. It's a bit of a kludge, I admit... >=20 > Should it really matter that some drivers cannot execute this command? > After all, the DB-API specifies rollback() as optional. Perhaps a formal > specification of a function like execute_immediate() could help here? > Optional for backends that support it. some drivers (at least three) already support the autocommit() call, that switches a connection to autocommit (i.e., immediate) mode. don't know if making it a standard would be usefull though. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Abandon the search for Truth; settle for a good fantasy. -- Anonymous --=-qEP0Anzi+tzjkzdzjR8b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Per informazioni si veda http://www.gnupg.org iEYEABECAAYFAjxptUkACgkQvcCgrgZGjevELQCfQ0xPSIbgdhVcixnUv5ZdxjHH ylsAoKpN061uaDpAl8LrHvzDd3le7gBP =oifu -----END PGP SIGNATURE----- --=-qEP0Anzi+tzjkzdzjR8b-- From jno@glasnet.ru Wed Feb 13 07:40:31 2002 From: jno@glasnet.ru (Eugene V. Dvurechenski) Date: Wed, 13 Feb 2002 10:40:31 +0300 Subject: [DB-SIG] create database in Python Database API 2.0 In-Reply-To: References: Message-ID: <20020213074031.GP889@glas.net> On Tue, Feb 12, 2002 at 11:34:52AM -0700, Dennis Sacks wrote: > I want to execute something like "create database" from python, yet I > cannot do it with a cursor.execute. why not? it's works just fine for me. i use DCOracle backend. -- 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 H.E.W.Frater@cs.cf.ac.uk Wed Feb 13 18:31:48 2002 From: H.E.W.Frater@cs.cf.ac.uk (Hugh Frater) Date: Wed, 13 Feb 2002 18:31:48 GMT0BST Subject: [DB-SIG] DCOracle help Message-ID: <3C6AB113.24942.5BA58F8@localhost> I'm a 1st year computer science student at Cardiff university, and have decided to use python to implement my first year project (WWW based library system). I have also decided to use the uni's oracle box to to the database stuff on. I've got the sys admin to install DCOracle, but am having real trouble with the following: I can't find any DCOracle documentation out there! And, If I try and create a cursor from my connection object, I get a message which says that cursor is not supported on my Connection object. Does anyone know what I'm doing wrong. I presume that my import oci_ line is OK? Any help would be great, Hugh Frater From clermont@us.ibm.com Wed Feb 13 16:47:28 2002 From: clermont@us.ibm.com (Teddy Clermont) Date: Wed, 13 Feb 2002 11:47:28 -0500 Subject: [DB-SIG] compiling DB2 module under Windows? Message-ID: The install file mention to copy a makefile.pre.in from python2.0/config . I have python22 install under windows 2000 and don't seem to have that makefile. The Windows _DB2.dll that comes with the tar file is compile with python 1.52. Question is how do I create the DLL using MS VC++ 6.0 Regards, P. Teddy Clermont. Senior Technical Consultant IBM Certified Solutions Expert - DB2 UDB V7.1 - Database Administration for Unix, Windows and OS/2 IBM SPC - Waltham 404 WymanSt Mailstop403 Waltham, MA 02254 clermont@us.ibm.com Phone:781-895-2908 - T/L: 362 FAX-781-895-2417 From andy47@halfcooked.com Thu Feb 14 00:27:03 2002 From: andy47@halfcooked.com (Andy Todd) Date: Thu, 14 Feb 2002 11:27:03 +1100 Subject: [DB-SIG] DCOracle help References: <3C6AB113.24942.5BA58F8@localhost> Message-ID: <3C6B0457.60009@halfcooked.com> Hugh, Welcome to the wonderful world of databases and Python. Hugh Frater wrote: > I'm a 1st year computer science student at Cardiff university, and > have decided to use python to implement my first year project (WWW > based library system). I have also decided to use the uni's oracle > box to to the database stuff on. I've got the sys admin to install > DCOracle, but am having real trouble with the following: > > I can't find any DCOracle documentation out there! http://www.zope.org/Products/DCOracle Should be your starting point. If its not there, it doesn't exist. > > And, > > If I try and create a cursor from my connection object, I get a > message which says that cursor is not supported on my Connection > object. Does anyone know what I'm doing wrong. I presume that my > import oci_ line is OK? > > Any help would be great, > Hugh Frater > Ah, now your other problem is that DCOracle is an old interface module and is largely deprecated these days - apart from folks who have it running like a dream of course ;-) The major drawback of DCOracle is that its written using the Oracle 7 OCI libraries and these are a definite no-no these days according to the lovely people at Redwood Shores. It will work with Oracle8i and above but you are into the realms of tin can and string solutions, so its best to use a more up to date interface module (like DCOracle2 or cx_Oracle). Its minor drawback is that it doesn't comply with the Python DB-API 2.0 (http://www.python.org/topics/database/DatabaseAPI-2.0.html) and most of the people on this list are more conversant with that syntax and would be able to be more helpful if you were too. If all else fails, perhaps you could post your code and we can take a stab at debugging it anyway. For starters, we could tell you whether or not your import line is OK. Regards, Andy -- ----------------------------------------------------------------------- From the desk of Andrew J Todd esq. "So I curtailed my Walpoling activities, sallied forth and infiltrated your place of purveyance to negotiate the vending of some cheesy comestibles." - Monty Python. From H.E.W.Frater@cs.cf.ac.uk Thu Feb 14 11:05:39 2002 From: H.E.W.Frater@cs.cf.ac.uk (Hugh Frater) Date: Thu, 14 Feb 2002 11:05:39 GMT0BST Subject: [DB-SIG] DCOracle Message-ID: <3C6B9A02.12458.BA103@localhost> Thanks for the replies I've had from you guys. I might try to get the sys admin to install DCOracle2, but I would like to try and get the current module working first. We use oracle 8i, but I think we still run something like 1.X python, not the new 2.x versions. I can import oci_ with: import oci_ and it works fine. I can also connect to oracel with my username/password fine but when I try to create a new cursor object (c = db.cursor()), I get this error: Attribut error: 'Connection' object has no attribute 'Cursor' Any ideas? Hugh From djc@object-craft.com.au Thu Feb 14 12:34:41 2002 From: djc@object-craft.com.au (Dave Cole) Date: 14 Feb 2002 23:34:41 +1100 Subject: [DB-SIG] Sybase module 0.33pre3 released In-Reply-To: Message-ID: What is it: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. Note: Since the 0.32 release I have come to the realisation that the Sybase dynamic SQL functionality is not nearly general enough to use for correct DB-API functionality. I have thrown up my hands and gone back to the drawing board with the high level Sybase.py module. Status of 0.33pre2: The 0.33pre2 release seems to be quite solid. I have not received any complaints from any of the 10 (count them) people who downloaded the module. Ben Gertzfield managed to implement a multi-threaded whois server on top of the 0.32pre2 release. Changes for 0.33pre3: 1) Release 0.32pre2 changed the paramstyle to 'format'. Shai Berger sent me some valuable advice on how to continue to send binary parameters to the server without using ct_dynamic() so the paramstyle is now 'named'. This means that you can now do this: c.execute("select * from titles where title like @arg", { '@arg': 'The %' }) 2) You can send arguments to Cursor.callproc() the old way: c.callproc('sp_help', ['titles']) or the new way: c.callproc('sp_help', { '@objname': 'titles' }) 3) Some internal cursor state constants were privatised (via leading '_'). Sadly no money was raised in the process and the conditions of the privatisation contract are commercial-in-confidence. 4) You can now compile the extension module without bulkcopy support by doing this: python setup.py build_ext -U WANT_BULKCOPY python setup.py install 5) The default build does not do threading any more so if you want threading enabled you will have to do this: python setup.py build_ext -D WANT_THREADS python setup.py install 6) There is some extra debugging detail for CS_DATAFMT which means you now get messages like this: >>> import Sybase >>> db = Sybase.connect('SYBASE', 'sa', '', 'pubs2') >>> db._conn.debug = 1 >>> c = db.cursor() ct_cmd_alloc(conn0, &cmd) -> CS_SUCCEED, cmd1 >>> c.callproc('sp_help', {'@objname': 'titles'}) ct_command(cmd1, CS_RPC_CMD, "sp_help", CS_NULLTERM, CS_UNUSED) -> CS_SUCCEED ct_param(cmd1, &databuf0->fmt=[name:"@objname" type:CS_CHAR_TYPE status:CS_INPUTVALUE format:CS_FMT_NULLTERM count:1 maxlength:7], databuf0->buff, 6, 0) -> CS_SUCCEED ct_send(cmd1) -> CS_SUCCEED ct_results(cmd1, &result) -> CS_SUCCEED, CS_ROW_RESULT ct_res_info(cmd1, CS_NUMDATA, &value, CS_UNUSED, NULL) -> CS_SUCCEED, 3 ct_describe(cmd1, 1, &fmt) -> CS_SUCCEED, datafmt0=[name:"Name" type:CS_CHAR_TYPE status:CS_UPDATABLE format:CS_FMT_UNUSED count:0 maxlength:30] ct_bind(cmd1, 1, &datafmt0->fmt=[name:"Name" type:CS_CHAR_TYPE status:CS_UPDATABLE format:CS_FMT_UNUSED count:1 maxlength:30], databuf1->buff, databuf1->copied, databuf1->indicator) -> CS_SUCCEED, databuf1 ct_describe(cmd1, 2, &fmt) -> CS_SUCCEED, datafmt1=[name:"Owner" type:CS_CHAR_TYPE status:48 format:CS_FMT_UNUSED count:0 maxlength:30] ct_bind(cmd1, 2, &datafmt1->fmt=[name:"Owner" type:CS_CHAR_TYPE status:48 format:CS_FMT_UNUSED count:1 maxlength:30], databuf2->buff, databuf2->copied, databuf2->indicator) -> CS_SUCCEED, databuf2 ct_describe(cmd1, 3, &fmt) -> CS_SUCCEED, datafmt2=[name:"Type" type:CS_CHAR_TYPE status:48 format:CS_FMT_UNUSED count:0 maxlength:22] ct_bind(cmd1, 3, &datafmt2->fmt=[name:"Type" type:CS_CHAR_TYPE status:48 format:CS_FMT_UNUSED count:1 maxlength:22], databuf3->buff, databuf3->copied, databuf3->indicator) -> CS_SUCCEED, databuf3 7) There is some initial work to support FreeTDS. One of the problems with FreeTDS is that it does not support inline error handling. The callback error handling works well if you do not compile for threads support, but causes problems when compiled for threading. The problem occurs when the extension module releases the global interpreter lock when calling the Sybase CT library. A Python callback causes the interpreter to be reentered by the callback which leads to bad things when the following warning from the Python include file ceval.h is violated: WARNING: NEVER NEST CALLS TO Py_BEGIN_ALLOW_THREADS AND Py_END_ALLOW_THREADS!!! At the moment the module will compile for FreeTDS (at least it does on my machine) and some things do work. All you have to do is compile like this: python setup.py build_ext -D HAVE_FREETDS python setup.py install There is no error handling and reporting for FreeTDS yet. 8) The was a minor change to setup.py for: a) Solaris. It no longer staticly links the libcomn.a Sybase library. b) Linux. No longer looks for both libsybtcl and libtcl. Now looks for libinsck. Extra Pleading: Please download the pre-release version, try it out, and then send me some mail telling me what you found. You would be surprised at how little mail I get regarding the Sybase module, I really do need your help. If more than 10 people tried the module we would all benefit... The module is available here: http://www.object-craft.com.au/projects/sybase/sybase-0.33pre3.tar.gz The module home page is here: http://www.object-craft.com.au/projects/sybase/ - Dave -- http://www.object-craft.com.au From diedrich@myriad.com Thu Feb 14 17:00:41 2002 From: diedrich@myriad.com (Karl Diedrich) Date: Thu, 14 Feb 2002 10:00:41 -0700 Subject: [DB-SIG] return list of dictionaries Message-ID: <3C6BED39.BD3B3034@myriad.com> Hello, Has anyone thought about alternatives to cursor.fetchXXX that return a list of dictionaries instead of a list of tuples. Then rows could be referenced by name. It would be easier to change code without breaking the order that has to be in the tuples. From jacobs@penguin.theopalgroup.com Thu Feb 14 17:07:26 2002 From: jacobs@penguin.theopalgroup.com (Kevin Jacobs) Date: Thu, 14 Feb 2002 12:07:26 -0500 (EST) Subject: [DB-SIG] return list of dictionaries In-Reply-To: <3C6BED39.BD3B3034@myriad.com> Message-ID: On Thu, 14 Feb 2002, Karl Diedrich wrote: > Has anyone thought about alternatives to cursor.fetchXXX that return a > list of dictionaries instead of > a list of tuples. > > Then rows could be referenced by name. It would be easier to change code > > without breaking the order that > has to be in the tuples. Yes, this has been tried and has some distinct disadvantages for naive implementations. However, there are some efficient alternatives that you may want to look at: http://www.lyra.org/greg/python/dtuple.py or my Python 2.2 module found on 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 mal@lemburg.com Thu Feb 14 17:14:07 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 14 Feb 2002 18:14:07 +0100 Subject: [DB-SIG] return list of dictionaries References: <3C6BED39.BD3B3034@myriad.com> Message-ID: <3C6BF05F.B00E4279@lemburg.com> Karl Diedrich wrote: > > Hello, > > Has anyone thought about alternatives to cursor.fetchXXX that return a > list of dictionaries instead of > a list of tuples. > > Then rows could be referenced by name. It would be easier to change code > > without breaking the order that > has to be in the tuples. This is a FAQ, please see the DB API 2.0 PEP Page at: http://python.sourceforge.net/peps/pep-0249.html -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mal@lemburg.com Thu Feb 14 17:20:43 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 14 Feb 2002 18:20:43 +0100 Subject: [DB-SIG] compiling DB2 module under Windows? References: Message-ID: <3C6BF1EB.112DE9F@lemburg.com> Teddy Clermont wrote: > > The install file mention to copy a makefile.pre.in from python2.0/config . > I have python22 install under windows 2000 and don't seem to have that > makefile. The Windows _DB2.dll that comes with the tar file is compile with > python 1.52. Question is how do I create the DLL using MS VC++ 6.0 Makefile.pre.in in deprecated in Python 2.2. You should create a simple distutils setup.py for the module and then compile it using distutils. > Regards, > P. Teddy Clermont. > Senior Technical Consultant > IBM Certified Solutions Expert - DB2 UDB V7.1 - > Database Administration for Unix, Windows and OS/2 > > IBM SPC - Waltham > 404 WymanSt Mailstop403 404 - that's a funny address ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From paul@boddie.net Thu Feb 14 17:25:36 2002 From: paul@boddie.net (paul@boddie.net) Date: 14 Feb 2002 17:25:36 -0000 Subject: [DB-SIG] DCOracle Message-ID: <20020214172536.18105.qmail@www1.nameplanet.com> "Hugh Frater" wrote: > >I can import oci_ with: >import oci_ First, I would seriously doubt that you should be importing something like oci_, although I've never used DCOracle, unless it's a rebranded form of the old oracledb module. (I don't think it is, though.) Can you not import something like DCOracle instead? >and it works fine. I can also connect to oracel with my >username/password fine but when I try to create a new cursor object >(c = db.cursor()), I get this error: >Attribut error: 'Connection' object has no attribute 'Cursor' You may have to be more specific. How did you get the connection? It seems like you're accessing some low-level implementation of the interface rather than the DB-API objects. If you can import DCOracle, what do you see when you do the following? dir(DCOracle) Can you find a function called "connect", "Connect" or even "DCOracle"? This should, when used with the username and password parameters, return a connection object which actually has a method called "cursor". See: http://www.python.org/topics/database/DatabaseAPI-2.0.html Hope this helps! Paul -- Get your firstname@lastname email at http://Nameplanet.com/?su From Matthew.Cahn@bms.com Thu Feb 14 22:01:17 2002 From: Matthew.Cahn@bms.com (Matthew Cahn) Date: Thu, 14 Feb 2002 17:01:17 -0500 Subject: [DB-SIG] DCOracle help References: <3C6AB113.24942.5BA58F8@localhost> <3C6B0457.60009@halfcooked.com> Message-ID: <3C6C33AC.4819CF0@bms.com> Hugh, I'd like to echo what Andy Todd said -- install DCOracle2: http://www.zope.org/Members/matt/dco2/ This document has some nice examples toward the end: http://www.zope.org/Members/matt/dco2/dco2doc I'm using the "latest" CVS version (well it was the latest a month ago). Regards, Matthew Cahn Andy Todd wrote: > Hugh, > > Welcome to the wonderful world of databases and Python. > > Hugh Frater wrote: > > > I'm a 1st year computer science student at Cardiff university, and > > have decided to use python to implement my first year project (WWW > > based library system). I have also decided to use the uni's oracle > > box to to the database stuff on. I've got the sys admin to install > > DCOracle, but am having real trouble with the following: > > > > I can't find any DCOracle documentation out there! > > http://www.zope.org/Products/DCOracle > > Should be your starting point. If its not there, it doesn't exist. > > > > > And, > > > > If I try and create a cursor from my connection object, I get a > > message which says that cursor is not supported on my Connection > > object. Does anyone know what I'm doing wrong. I presume that my > > import oci_ line is OK? > > > > Any help would be great, > > Hugh Frater > > > > Ah, now your other problem is that DCOracle is an old interface module > and is largely deprecated these days - apart from folks who have it > running like a dream of course ;-) > > The major drawback of DCOracle is that its written using the Oracle 7 > OCI libraries and these are a definite no-no these days according to the > lovely people at Redwood Shores. It will work with Oracle8i and above > but you are into the realms of tin can and string solutions, so its best > to use a more up to date interface module (like DCOracle2 or cx_Oracle). > > Its minor drawback is that it doesn't comply with the Python DB-API 2.0 > (http://www.python.org/topics/database/DatabaseAPI-2.0.html) and most of > the people on this list are more conversant with that syntax and would > be able to be more helpful if you were too. > > If all else fails, perhaps you could post your code and we can take a > stab at debugging it anyway. For starters, we could tell you whether or > not your import line is OK. > > Regards, > Andy > -- > ----------------------------------------------------------------------- > From the desk of Andrew J Todd esq. > "So I curtailed my Walpoling activities, sallied forth and infiltrated > your place of purveyance to negotiate the vending of some cheesy > comestibles." - Monty Python. > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From djc@object-craft.com.au Fri Feb 15 10:23:39 2002 From: djc@object-craft.com.au (Dave Cole) Date: 15 Feb 2002 21:23:39 +1100 Subject: [DB-SIG] Re: Sybase module 0.33pre4 released In-Reply-To: Message-ID: What is it: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. Note: Since the 0.32 release I have come to the realisation that the Sybase dynamic SQL functionality is not nearly general enough to use for correct DB-API functionality. I have thrown up my hands and gone back to the drawing board with the high level Sybase.py module. Status of 0.33pre2, 0.33pre3: The 0.33pre2 release seems to be quite solid. I have not received any complaints from any of the 10 (count them) people who downloaded the module. Ben Gertzfield managed to implement a multi-threaded whois server on top of the 0.32pre2 release. The only problems reported for 0.33pre3 were the Solaris build needed tweaking and the tar file unpacks to an unversioned directory. Changes for 0.33pre4: 1) In implementing some sample code to assist a user I discovered a threading locking problem with the Cursor.__del__() method. Management of the Cursor related Connection locks has been reimplemented. 2) Solaris build has been fixed again - thanks to Kent Polk. 3) The tar file now unpacks to a directory called sybase-. The changes for this release are so slight that I am inclined to mark release this as the next stable release in a week or so. Extra Extra Pleading: Please download the pre-release version, try it out, and then send me some mail telling me what you found. You would be surprised at how little mail I get regarding the Sybase module, I really do need your help. If more than 7 to 10 people tried the module we would all benefit... The module is available here: http://www.object-craft.com.au/projects/sybase/sybase-0.33pre4.tar.gz The module home page is here: http://www.object-craft.com.au/projects/sybase/ - Dave -- http://www.object-craft.com.au From matt@zope.com Fri Feb 15 13:38:52 2002 From: matt@zope.com (Matthew T. Kromer) Date: Fri, 15 Feb 2002 08:38:52 -0500 Subject: [DB-SIG] DCOracle help References: <3C6AB113.24942.5BA58F8@localhost> Message-ID: <009101c1b626$1c6e7ce0$0501010a@mi.org> Hi Hugh, I strongly recommend DCOracle2 instead, I've got a much richer set of documentation (although I doubt it is perfect). You can download this from www.zope.org/Members/matt/dco2 or via cvs.zope.org. ----- Original Message ----- From: "Hugh Frater" To: Sent: Wednesday, February 13, 2002 1:31 PM Subject: [DB-SIG] DCOracle help > I'm a 1st year computer science student at Cardiff university, and > have decided to use python to implement my first year project (WWW > based library system). I have also decided to use the uni's oracle > box to to the database stuff on. I've got the sys admin to install > DCOracle, but am having real trouble with the following: > > I can't find any DCOracle documentation out there! > > And, > > If I try and create a cursor from my connection object, I get a > message which says that cursor is not supported on my Connection > object. Does anyone know what I'm doing wrong. I presume that my > import oci_ line is OK? > > Any help would be great, > Hugh Frater > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > From H.E.W.Frater@cs.cf.ac.uk Fri Feb 15 15:29:51 2002 From: H.E.W.Frater@cs.cf.ac.uk (Hugh Frater) Date: Fri, 15 Feb 2002 15:29:51 GMT0BST Subject: [DB-SIG] DCOracle2 Message-ID: <3C6D296E.24611.B981ED@localhost> Thanks for all the help guys. were running python 1.5.1 on our departmental servers, and was wondering if DCOracle2 will work with this, or does it need version 2.0 or greater? Hugh From matt@zope.com Fri Feb 15 15:41:33 2002 From: matt@zope.com (Matthew T. Kromer) Date: Fri, 15 Feb 2002 10:41:33 -0500 Subject: [DB-SIG] DCOracle2 References: <3C6D296E.24611.B981ED@localhost> Message-ID: <3C6D2C2D.3020101@zope.com> Hugh Frater wrote: >Thanks for all the help guys. were running python 1.5.1 on our >departmental servers, and was wondering if DCOracle2 will work with >this, or does it need version 2.0 or greater? > >Hugh > >_______________________________________________ >DB-SIG maillist - DB-SIG@python.org >http://mail.python.org/mailman/listinfo/db-sig > It should ... but python 1.5.1 is old enough that I just dont know if it won't. I cant think of any reason why it wouldn't -- but I haven't run Python 1.5.1 for ... 3 years? (Redhat 5.2 days). -- Matt Kromer Zope Corporation http://www.zope.com/ From brunson@level3.net Sun Feb 17 05:27:43 2002 From: brunson@level3.net (Eric Brunson) Date: Sat, 16 Feb 2002 22:27:43 -0700 Subject: [DB-SIG] DCOracle2 In-Reply-To: <3C6D296E.24611.B981ED@localhost> References: <3C6D296E.24611.B981ED@localhost> Message-ID: <20020216222743.A22533@level3.net> You should ask your admin to install python 2.2 alongside 1.5, install DCOracle2 in your own lib path. If this doesn't work out grab the DCOracle2 package off Zope and try building it with 1.5.1 (*seriously* out of date, btw). We'll help if you have problems, I've got it running under 1.5.2. * Hugh Frater (H.E.W.Frater@cs.cf.ac.uk) [020215 08:30]: > Thanks for all the help guys. were running python 1.5.1 on our > departmental servers, and was wondering if DCOracle2 will work with > this, or does it need version 2.0 or greater? > > Hugh > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Eric Brunson brunson@level3.net page-eric@level3.net tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY From dario@ita.chalmers.se Fri Feb 22 14:49:26 2002 From: dario@ita.chalmers.se (=?iso-8859-1?Q?Dario_Lopez-K=E4sten?=) Date: Fri, 22 Feb 2002 15:49:26 +0100 Subject: [DB-SIG] DCOracle help References: <3C6AB113.24942.5BA58F8@localhost> <3C6B0457.60009@halfcooked.com> <3C6C33AC.4819CF0@bms.com> Message-ID: <04b501c1bbb0$204c8b10$4bdf1081@ita.chalmers.se> From: "Matthew Cahn" > I'm using the "latest" CVS version (well it was the latest a month ago). > > Regards, > Matthew Cahn Anyone using DCO2 and need to use null-values (ie in queries or results) should use the latest cvs version. IT has a number of bugfixes regarding nulls. My 0.02 /dario :-) - -------------------------------------------------------------------- Dario Lopez-K=E4sten Systems Developer Chalmers Univ. of Technology dario@ita.chalmers.se ICQ will yield no hits IT Systems & Services From marif@alvin.stmarytx.edu Wed Feb 27 12:10:44 2002 From: marif@alvin.stmarytx.edu (Mubaraka Arif) Date: Wed, 27 Feb 2002 06:10:44 -0600 Subject: [DB-SIG] Probelm with inserting into postgres database using the pg module of python Message-ID: <20020227061044.E10026@neptune.stmarytx.edu> please can someone send me a working code sample how they successfully used the pg module to insert one or more rows into an postgres database. However , although I can query the database I have no success at inserting rows, except by hardcoding the values into the sql string. I would appreciate yr help Mubaraka From marif@alvin.stmarytx.edu Wed Feb 27 17:25:26 2002 From: marif@alvin.stmarytx.edu (Mubaraka Arif) Date: Wed, 27 Feb 2002 11:25:26 -0600 Subject: [DB-SIG] Re: Probelem with inserting into postgres database using python In-Reply-To: ; from Mailer-Daemon@alvin.stmarytx.edu on Wed, Feb 27, 2002 at 16:46:09 -0600 References: Message-ID: <20020227112526.I10026@neptune.stmarytx.edu> On 2002.02.27 16:46 Mail Delivery System wrote: > This message was created automatically by mail delivery software. > > A message that you sent could not be delivered to all of its > recipients. The > following address(es) failed: > > db-dig@python.org: > SMTP error from remote mailer after RCPT TO: > : > host mail.python.org [63.102.49.29]: > 550 Unknown local part db-dig in > > > hey Kelvin, > > Thanks for providing sample code accessing postgres database thru > python interface. Earlier , i was using the "pg" module which worked > fine , but it would not allow cursor handling. But yr approach thru > "pgdb" interface uses the cursor mechanisms , so I shall include it in > > my development too. > > Thanks and I appreciate yr help ! > > Mubaraka Arif > Data Management Software Developer > St, Mary's UNiversity, TX > Administrative Technology and Information Services > ph: (210)- 525-8056 > email - marif@alvin.stmarytx.edu > > On 2002.02.27 12:31 Kevin Cole wrote: > > Hi, > > > > I've attached an example of how to insert with Python. I stripped > > down > > an application that I wrote. It may not be the most efficient way > to > > do > > things but it appears to work fine for us. > > > > I hope it helps you. > > -- > > 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 > > > > #!/usr/bin/env python > > from sys import * # Which OS are we using? > > import os # Operating system functions > > import os.path # Ditto > > import pgdb # PostgreSQL interface > > > > bookstore = pgdb.connect("localhost:boox") # Open the "boox" > > database > > newz = bookstore.cursor() # Establish a > > "cursor" > > > > > ######################################################################### > > # DELETED: Gather data from web form, error-check it, make sure the > > ID # > > # field is unique, etc, > etc. > > > # > > > ######################################################################### > > > > inst = replace(title, "'", "''") # Escape all single > > quotes > > insw = replace(author, "'", "''") > > insk = replace(keywords, "'", "''") > > insa = replace(abstract, "'", "''") > > values = (id,yr,issue,page,article,inst,insw,insk,insa,pdf,touched) > > insert = "insert into newz values > > (%s,%s,%s,%s,%s,'%s','%s','%s','%s','%s','%s');" > > newz.execute(insert % (values)) > > boox.commit() > > > > From marif@alvin.stmarytx.edu Thu Feb 28 08:59:20 2002 From: marif@alvin.stmarytx.edu (Mubaraka Arif) Date: Thu, 28 Feb 2002 02:59:20 -0600 Subject: [DB-SIG] Re: Probelem with inserting into postgres database using python In-Reply-To: <20020227112526.I10026@neptune.stmarytx.edu>; from marif@alvin.stmarytx.edu on Wed, Feb 27, 2002 at 11:25:26 -0600 References: <20020227112526.I10026@neptune.stmarytx.edu> Message-ID: <20020228025920.A11281@neptune.stmarytx.edu> >> hey Kelvin, >> >> Thanks for providing sample code accessing postgres database thru >> python interface. Earlier , i was using the "pg" module which worked >> fine , but it would not allow cursor handling. But yr approach thru >> "pgdb" interface uses the cursor mechanisms , so I shall include it >> in my development too. >> >> Thanks and I appreciate yr help ! >> >> Mubaraka Arif >> Data Management Software Developer >> St, Mary's UNiversity, TX >> Administrative Technology and Information Services >> ph: (210)- 525-8056 >> email - marif@alvin.stmarytx.edu >> >> On 2002.02.27 12:31 Kevin Cole wrote: >> > Hi, >> > >> > I've attached an example of how to insert with Python. I stripped >> > down >> > an application that I wrote. It may not be the most efficient way >> to >> > do >> > things but it appears to work fine for us. >> > >> > I hope it helps you. >> > -- >> > 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 >> > >> > #!/usr/bin/env python >> > from sys import * # Which OS are we using? >> > import os # Operating system >> functions >> > import os.path # Ditto >> > import pgdb # PostgreSQL interface >> > >> > bookstore = pgdb.connect("localhost:boox") # Open the "boox" >> > database >> > newz = bookstore.cursor() # Establish a >> > "cursor" >> > >> > >> ######################################################################### >> > # DELETED: Gather data from web form, error-check it, make sure the >> > ID # >> > # field is unique, etc, >> etc. > # >> > >> ######################################################################### >> > >> > inst = replace(title, "'", "''") # Escape all single >> > quotes >> > insw = replace(author, "'", "''") >> > insk = replace(keywords, "'", "''") >> > insa = replace(abstract, "'", "''") >> > values = (id,yr,issue,page,article,inst,insw,insk,insa,pdf,touched) >> > insert = "insert into newz values >> > (%s,%s,%s,%s,%s,'%s','%s','%s','%s','%s','%s');" >> > newz.execute(insert % (values)) >> > boox.commit() >> > >> >> > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig >