From adustman@comstar.net Mon Aug 2 05:25:55 1999 From: adustman@comstar.net (Andy Dustman) Date: Mon, 2 Aug 1999 00:25:55 -0400 (EDT) Subject: [DB-SIG] Patch for MySQLdb-0.0.3 In-Reply-To: <37A1EE6A.F898AEE1@dnr.state.ak.us> Message-ID: I don't have time to put 0.0.4 together for a while, but this will probably be the only change. This fixes a bug introduced in 0.0.3 where if an exception is raised during the connect(), it dumps core. Index: _mysqlmodule.c =================================================================== RCS file: /usr1/cvsroot/python/mysql/_mysqlmodule.c,v retrieving revision 1.13 diff -u -r1.13 _mysqlmodule.c --- _mysqlmodule.c 1999/07/20 04:04:20 1.13 +++ _mysqlmodule.c 1999/08/02 04:15:13 @@ -399,6 +399,15 @@ &port, &unix_socket, &client_flag, &conv)) return NULL; + if (conv) { + c->converter = conv; + Py_INCREF(conv); + } else { + if (!(c->converter = PyDict_New())) { + Py_DECREF(c); + return NULL; + } + } Py_BEGIN_ALLOW_THREADS ; conn = mysql_init(&(c->connection)); conn = mysql_real_connect(&(c->connection), host, user, passwd, db, @@ -410,15 +419,6 @@ return NULL; } c->open = 1; - if (conv) { - c->converter = conv; - Py_INCREF(conv); - } else { - if (!(c->converter = PyDict_New())) { - Py_DECREF(c); - return NULL; - } - } return (PyObject *) c; } -- andy dustman | programmer/analyst | comstar communications corporation telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From sabaini@styria.com Tue Aug 10 17:56:08 1999 From: sabaini@styria.com (Peter Sabaini) Date: Tue, 10 Aug 1999 18:56:08 +0200 Subject: [DB-SIG] mysqlmodule wont compile Message-ID: <37B059A8.F7CE6AB8@styria.com> hubu, MySQLmodule 1.14 wont compile on my system anbody any ideas? tia peter s. # uname -a Linux hastings 2.2.10 #2 Mon Aug 9 10:58:56 MEST 1999 i586 unknown # gcc --version 2.7.2.3 # ./configure --with-threads # make gcc -I/opt/mysql/include/mysql -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./MySQLmodule.c ./MySQLmodule.c: In function `pythonify_row': ./MySQLmodule.c:238: warning: assignment from incompatible pointer type ./MySQLmodule.c: In function `pythonify_res_fields': ./MySQLmodule.c:384: invalid lvalue in unary `&' ./MySQLmodule.c: In function `STH_fetchdict': ./MySQLmodule.c:1125: invalid lvalue in unary `&' ./MySQLmodule.c:1147: invalid lvalue in unary `&' make[1]: *** [MySQLmodule.o] Error 1 From adustman@comstar.net Tue Aug 10 18:32:17 1999 From: adustman@comstar.net (Andy Dustman) Date: Tue, 10 Aug 1999 13:32:17 -0400 (EDT) Subject: [DB-SIG] mysqlmodule wont compile In-Reply-To: <37B059A8.F7CE6AB8@styria.com> Message-ID: On Tue, 10 Aug 1999, Peter Sabaini wrote: > hubu, > > MySQLmodule 1.14 wont compile on my system You mean 1.4, maybe? > anbody any ideas? What version MySQL do you have? You probably need 3.21 for MySQLmodule. I have my own interface for MySQL-3.22 located at: http://starship.python.net/crew/adustman That may work better for you. Requires Python 1.5.2. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From lgreene@techsatwork.com Wed Aug 11 21:56:49 1999 From: lgreene@techsatwork.com (Larry Greene) Date: Wed, 11 Aug 1999 16:56:49 -0400 Subject: [DB-SIG] DCOracle-1.2.1 Message-ID: <001201bee43c$081c84d0$333eb326@techsatwork.com> This is a multi-part message in MIME format. ------=_NextPart_000_000F_01BEE41A.80F253C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, We are attempting to install DCOracle on our IBM RS/6000 under AIX=20 with numerous unresolved problems. We want to be able to connect to our Oracle-8.0.5 database with Python-1.5.2.=20 Has anyone experienced this combination of elements in an installation? Your input would be greatly appreciated! TIA Larry Greene ------=_NextPart_000_000F_01BEE41A.80F253C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
We are attempting to install DCOracle on our IBM RS/6000 under AIX =
with numerous unresolved problems.  We want to be able = to=20 connect
to our Oracle-8.0.5 database with Python-1.5.2.
 
Has anyone experienced this combination of elements in an=20 installation?
 
Your input would be greatly appreciated!
 
TIA
 
 
Larry Greene
 
------=_NextPart_000_000F_01BEE41A.80F253C0-- From sabaini@styria.com Thu Aug 12 08:17:15 1999 From: sabaini@styria.com (Peter Sabaini) Date: Thu, 12 Aug 1999 09:17:15 +0200 Subject: [DB-SIG] mysqlmodule wont compile References: Message-ID: <37B274FB.4F529539@styria.com> Andy Dustman wrote: > > On Tue, 10 Aug 1999, Peter Sabaini wrote: > > > MySQLmodule 1.14 wont compile on my system > > You mean 1.4, maybe? ehm yes of course... sorry > > anbody any ideas? > > What version MySQL do you have? You probably need 3.21 for MySQLmodule. I > have my own interface for MySQL-3.22 located at: do you mean 3.21 _or_higher_ or that exact version? i tried it with 3.22 and 3.23. i'll try it with 3.21. > http://starship.python.net/crew/adustman > > That may work better for you. Requires Python 1.5.2. unfortunately i need it to work with zope (http://zope.org) so i guess i'm stuck with MySQLmodule thank you anyway. peter. From adustman@comstar.net Thu Aug 12 15:07:32 1999 From: adustman@comstar.net (Andy Dustman) Date: Thu, 12 Aug 1999 10:07:32 -0400 (EDT) Subject: [DB-SIG] mysqlmodule wont compile In-Reply-To: <37B274FB.4F529539@styria.com> Message-ID: On Thu, 12 Aug 1999, Peter Sabaini wrote: > > What version MySQL do you have? You probably need 3.21 for MySQLmodule. I > > have my own interface for MySQL-3.22 located at: > > do you mean 3.21 _or_higher_ or that exact version? i tried it with > 3.22 and 3.23. i'll try it with 3.21. It's designed to work with 3.21 according to the README, so newer versions might not work. > > http://starship.python.net/crew/adustman > > > > That may work better for you. Requires Python 1.5.2. > > unfortunately i need it to work with zope (http://zope.org) so i > guess i'm stuck with MySQLmodule Zope is apparently going to be switching to MySQLdb, due to problems with thread blocking in MySQLmodule. The current version of MySQLdb has a patch to change Zope's ZMySQLDA to use MySQLdb (actually it's underlying _mysql module). It is not quite right yet. If you change error to Error in one spot, it works a little. I've fallen behind on the Zope list a bit lately, so I'm not sure what the status of things are. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From schneckener@lion-ag.de Mon Aug 16 14:04:54 1999 From: schneckener@lion-ag.de (Sebastian Schneckener) Date: Mon, 16 Aug 1999 15:04:54 +0200 Subject: [DB-SIG] DCOracle/dbi.dbiDate Message-ID: <37B80C76.A85F5DF7@Lion-AG.de> hello everybody when retrieving a date item from oracle using the DCOracle module, I retrieve a dbiDate instance. How can this be converted into ticks? thanks Sebastian Schneckener From mal@lemburg.com Mon Aug 16 16:23:16 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 16 Aug 1999 17:23:16 +0200 Subject: [DB-SIG] DCOracle/dbi.dbiDate References: <37B80C76.A85F5DF7@Lion-AG.de> Message-ID: <37B82CE4.50399633@lemburg.com> Sebastian Schneckener wrote: > > hello everybody > > when retrieving a date item from oracle using the DCOracle module, I retrieve a dbiDate instance. > How can this be converted into ticks? Have you tried int(object), float(object) or object.value ? -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 138 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From dzhao@primeon.com Tue Aug 17 05:01:06 1999 From: dzhao@primeon.com (Di Zhao) Date: Tue, 17 Aug 1999 00:01:06 -0400 (EDT) Subject: [DB-SIG] DCOracle-1.2.1 on RH6.0 for Oracle 8.1.5 Message-ID: Has anyone sucessfully built DCOracle for Oracle 8.1.5 on Solaris?? I am about to choose Python as the major development tool for a project but fear that such combination won't work. BTW, I only find a 8.0.4 setup file in the package, I hope the two versions of Oracle won't be drastically different so that I could make it work:) --Code is art. It is the lasting output of a union of hacker, computer, and documentation. To patent an algorithm embodied in code is like patenting impressionism or the sonata. To defend such a patent is vile censorship and persecution. by John Tobey Email: dzhao@primeon.com, zhao_di@hotmail.com From bkc@murkworks.com Wed Aug 25 16:23:00 1999 From: bkc@murkworks.com (Brad Clements) Date: Wed, 25 Aug 1999 11:23:00 -0400 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected Message-ID: <199908251516.LAA12211@anvil.murkworks.com> I'm writing an ADO DA for Python to the 2.0 DB spec. I've run into two problems: 1. The threading level isn't known until a connection is established, since ADO can connect through ODBC, Ole DB and other providers, the thread safety isn't set until connected. Is it reasonable to extend the 2.0 spec to say that if connection.threadsafety exists, use that instead of a module level variable? 2. Transactions - I don't see a connection.begintransaction() method, just rollback() and commit(). The spec mentions that auto-commit has to be disabled, so how does a person turn it on? Why wasn't begintransaction() included in the spec? Simply calling commit() to turn on transactions is rather ugly, since the first transaction won't be able to be rolled-back. Same problem as in 1, I won't know if transactions are supported until a connection is established. Given that thread safety, and transactions are per-connection in this DA, what is the best way to support this concept within the bounds of the 2.0 spec? Since begintransaction() is not specified in the spec, what is the recommended method for auto-commit vs auto-begin, etc? I'd prefer, and will need, an explicit begin,commit for use with Zope. Whats the recommended way to merge this in? Thanks.. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From mal@lemburg.com Wed Aug 25 17:44:08 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 25 Aug 1999 18:44:08 +0200 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected References: <199908251516.LAA12211@anvil.murkworks.com> Message-ID: <37C41D58.7C1E12A1@lemburg.com> Brad Clements wrote: > > I'm writing an ADO DA for Python to the 2.0 DB spec. > > I've run into two problems: > > 1. The threading level isn't known until a connection is established, > since ADO can connect through ODBC, Ole DB and other providers, the > thread safety isn't set until connected. > > Is it reasonable to extend the 2.0 spec to say that if > connection.threadsafety exists, use that instead of a module level > variable? I'd suggest setting the module level variable to the lowest level and then add a per connection attribute as you indicated. > 2. Transactions - I don't see a connection.begintransaction() method, > just rollback() and commit(). The spec mentions that auto-commit has > to be disabled, so how does a person turn it on? Why wasn't > begintransaction() included in the spec? Simply calling commit() to turn > on transactions is rather ugly, since the first transaction won't be able to > be rolled-back. When the cursor is created an implicit transactions start is performed. This is normal SQL behaviour. You don't need to do a .commit() to start a new transaction. Auto-commit is enabled per default for ODBC. Since it renders transactions useless (you can't rollback), the DB API spec explicitly states to turn it off per default. You can provide a method to turn it back on again, if you like, e.g. mxODBC has connection.setconnectoption(option,value) which allows you to reenable auto-commit. Connections that don't support transactions should not implement the .rollback() method or raise a NotSupportedError exception whenever the method is called. > Same problem as in 1, I won't know if transactions are supported until a > connection is established. > > Given that thread safety, and transactions are per-connection in this > DA, what is the best way to support this concept within the bounds of > the 2.0 spec? > > Since begintransaction() is not specified in the spec, what is the > recommended method for auto-commit vs auto-begin, etc? I'd prefer, > and will need, an explicit begin,commit for use with Zope. Whats the > recommended way to merge this in? Make the .rollback() method dynamically defined, i.e. have it disabled on connections that do not support transactions. An explicit "begin transaction" is not needed since this always happens implicitly when you call connection.cursor() or cursor.commit()/ .rollback(). Cheers, -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 128 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ZakonS@eccelerate.com Wed Aug 25 17:54:26 1999 From: ZakonS@eccelerate.com (Zakon, Stuart) Date: Wed, 25 Aug 1999 12:54:26 -0400 Subject: [DB-SIG] FW: [PyGreSQL] DB API v2.0? Message-ID: This is a thread forwarded from the PyGreSQL mailing list. We are polling for interest in doing a DB-API 2.0 interface to PostgreSQL. Any interest out there? Stuart > -----Original Message----- > From: Zakon, Stuart [SMTP:ZakonS@eccelerate.com] > Sent: Wednesday, August 18, 1999 9:27 AM > To: PyGreSQL@vex.net > Subject: RE: [PyGreSQL] DB API v2.0? > > D'Arcy, > > I latched on to PostgreSQL from the LinuxWorld award and writeup. > I'm assuming that this will generate a lot of interest in general in > PostgreSQL. > However, like others, I want to stay close to DB API 2.0 so that my app > can port to multiple database platforms. Based on increased interest in > PostgreSQL, it would make sense to stimulate interest in the developer > community to get a DB API 2.0 wrapper. How about posting to > comp.lang.python? > Or does the database SIG have a mailing list? There should be interest out > there > for this from somebody with experience in the API. > > Good luck, > Stuart > > > -----Original Message----- > > From: D'Arcy" "J.M." Cain [SMTP:darcy@druid.druid.net] > > Sent: Tuesday, August 17, 1999 9:56 PM > > To: PyGreSQL@vex.net > > Subject: Re: [PyGreSQL] DB API v2.0? > > > > Thus spake Zakon, Stuart > > > Hi, > > > I am hunting for a python module that will support DB API v2.0 to > > > PostgreSQL. > > > I didn't see anything on your site indicating support for this. > > > Is the PygreSQL team going to support this API? Are there technical > > > reasons why this might not be done? > > > > Well, the plan was that 3.0 would be the version with DB API support. > > Unfortunately real life keeps tripping me up. Basically, Andre > > Pascal, the gentleman who wrote PyGres95 upon which PyGreSQL is > > based, was going to supply patches to add that in. I don't know > > enough about the DB API to write it myself so I depend on others. > > I haven't heard from him for a while so I imagine that he is busy > > and I have been busy too so I haven't been able to follow up with him. > > > > The general idea is to add support functions into the C module to > > support the functionality. Then, we would write another wrapper > > around the _pg module like the pg one. That way both interfaces > > are available. I can probably start posting some of the discussions > > Andre and I have been having in case others would like to jump in and > > help out. I suppose I should ask Andre first although he has been > > agreeable to my posting his email before. Since he is subscribed > > to this list I assume he will see this and take it as a request. > > > > After all, the whole point of open source software is to get the > > advantage of that huge pool of potential developers. We may as > > well tap into it. I expect to have some spare time around mid > > to end September. Anyone interested in ramping up this project > > around then? If so then I can start posting things for discussion > > purposes and hopefully when we are ready to do the real work we > > will have all our directions figured out. > > > > -- > > D'Arcy J.M. Cain | Democracy is three wolves > > http://www.druid.net/darcy/ | and a sheep voting on > > +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. > > > ------------------------------------------------------------------------- > > PyGreSQL Mailing List > > Send requests to majordomo@vex.net > ------------------------------------------------------------------------- > PyGreSQL Mailing List > Send requests to majordomo@vex.net From bkc@murkworks.com Wed Aug 25 19:27:39 1999 From: bkc@murkworks.com (Brad Clements) Date: Wed, 25 Aug 1999 14:27:39 -0400 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <37C41D58.7C1E12A1@lemburg.com> Message-ID: <199908251821.OAA12402@anvil.murkworks.com> On 25 Aug 99, at 18:44, M.-A. Lemburg wrote: > I'd suggest setting the module level variable to the lowest > level and then add a per connection attribute as you indicated. Ok. > When the cursor is created an implicit transactions start is > performed. This is normal SQL behaviour. You don't need to do > a .commit() to start a new transaction. True but, I need to tell ADO that I want to support transactions. If the user never calls commit, how do I know that I should enable transactions? > > Auto-commit is enabled per default for ODBC. Since it renders ADO doesn't have to use ODBC, in fact I suspect most folks won't be using the ODBC driver via ADO. The "Ole DB SQL Provider" and also, I think, the Oracle one, assume that transactions are not used unless I turn them on. If I just enable transactions, then do a BeginTransaction when issuing a cursor, how do I know when to do a Commit() since auto-commit is supposed to be disabled, and the user may never call connection.commit()? > Make the .rollback() method dynamically defined, i.e. have it > disabled on connections that do not support transactions. An explicit > "begin transaction" is not needed since this always happens > implicitly when you call connection.cursor() or cursor.commit()/ > .rollback(). Er, well, I can't find in the 2.0 spec anywhere that it says that constructing a new cursor automatically begins a transaction. My DA has to explicitely call the underlying begin, commit and rollback as appropriate. Either I'm blind, or the DA 2.0 spec doesn't say enough about transactions, automatic or otherwise, for me to know when I should begin a new transaction. Can anyone point to archived discussion that talks about this subject, I couldn't find any. Thanks Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From adustman@comstar.net Wed Aug 25 21:49:14 1999 From: adustman@comstar.net (Andy Dustman) Date: Wed, 25 Aug 1999 16:49:14 -0400 (EDT) Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <199908251821.OAA12402@anvil.murkworks.com> Message-ID: On Wed, 25 Aug 1999, Brad Clements wrote: > On 25 Aug 99, at 18:44, M.-A. Lemburg wrote: > > > Make the .rollback() method dynamically defined, i.e. have it > > disabled on connections that do not support transactions. An explicit > > "begin transaction" is not needed since this always happens > > implicitly when you call connection.cursor() or cursor.commit()/ > > .rollback(). > > Er, well, I can't find in the 2.0 spec anywhere that it says that > constructing a new cursor automatically begins a transaction. In standard SQL, a transaction begins once you start executing SQL statements (there's probably a more rigorous definition of this), and ends when you execute COMMIT WORK or ROLLBACK WORK. There's no command that explicitely begins a transaction. > My DA has to explicitely call the underlying begin, commit and rollback > as appropriate. Either I'm blind, or the DA 2.0 spec doesn't say enough > about transactions, automatic or otherwise, for me to know when I > should begin a new transaction. If your database requires an explicit command to begin a new transaction, that's a little weird. I would suggest executing the begin when you initialize the cursor. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d From mwa@gate.net Wed Aug 25 22:47:32 1999 From: mwa@gate.net (Mark W. Alexander) Date: Wed, 25 Aug 1999 17:47:32 -0400 (EDT) Subject: [DB-SIG] FW: [PyGreSQL] DB API v2.0? In-Reply-To: Message-ID: Yes! I've been trying to find the time. I've got a fair amount of PyGreSQL stuff that I wish was more portable. Let me know if this will be on db-sig or the PyGreSQL list. I'm not currently on the PyGreSQL list. Mark Alexander mwa@gate.net On Wed, 25 Aug 1999, Zakon, Stuart wrote: > Date: Wed, 25 Aug 1999 12:54:26 -0400 > From: "Zakon, Stuart" > To: db-sig@python.org > Subject: [DB-SIG] FW: [PyGreSQL] DB API v2.0? > > This is a thread forwarded from the PyGreSQL mailing list. > We are polling for interest in doing a DB-API 2.0 interface to PostgreSQL. > Any interest out there? > > Stuart > > > -----Original Message----- > > From: Zakon, Stuart [SMTP:ZakonS@eccelerate.com] > > Sent: Wednesday, August 18, 1999 9:27 AM > > To: PyGreSQL@vex.net > > Subject: RE: [PyGreSQL] DB API v2.0? > > > > D'Arcy, > > > > I latched on to PostgreSQL from the LinuxWorld award and writeup. > > I'm assuming that this will generate a lot of interest in general in > > PostgreSQL. > > However, like others, I want to stay close to DB API 2.0 so that my app > > can port to multiple database platforms. Based on increased interest in > > PostgreSQL, it would make sense to stimulate interest in the developer > > community to get a DB API 2.0 wrapper. How about posting to > > comp.lang.python? > > Or does the database SIG have a mailing list? There should be interest out > > there > > for this from somebody with experience in the API. > > > > Good luck, > > Stuart > > > > > -----Original Message----- > > > From: D'Arcy" "J.M." Cain [SMTP:darcy@druid.druid.net] > > > Sent: Tuesday, August 17, 1999 9:56 PM > > > To: PyGreSQL@vex.net > > > Subject: Re: [PyGreSQL] DB API v2.0? > > > > > > Thus spake Zakon, Stuart > > > > Hi, > > > > I am hunting for a python module that will support DB API v2.0 to > > > > PostgreSQL. > > > > I didn't see anything on your site indicating support for this. > > > > Is the PygreSQL team going to support this API? Are there technical > > > > reasons why this might not be done? > > > > > > Well, the plan was that 3.0 would be the version with DB API support. > > > Unfortunately real life keeps tripping me up. Basically, Andre > > > Pascal, the gentleman who wrote PyGres95 upon which PyGreSQL is > > > based, was going to supply patches to add that in. I don't know > > > enough about the DB API to write it myself so I depend on others. > > > I haven't heard from him for a while so I imagine that he is busy > > > and I have been busy too so I haven't been able to follow up with him. > > > > > > The general idea is to add support functions into the C module to > > > support the functionality. Then, we would write another wrapper > > > around the _pg module like the pg one. That way both interfaces > > > are available. I can probably start posting some of the discussions > > > Andre and I have been having in case others would like to jump in and > > > help out. I suppose I should ask Andre first although he has been > > > agreeable to my posting his email before. Since he is subscribed > > > to this list I assume he will see this and take it as a request. > > > > > > After all, the whole point of open source software is to get the > > > advantage of that huge pool of potential developers. We may as > > > well tap into it. I expect to have some spare time around mid > > > to end September. Anyone interested in ramping up this project > > > around then? If so then I can start posting things for discussion > > > purposes and hopefully when we are ready to do the real work we > > > will have all our directions figured out. > > > > > > -- > > > D'Arcy J.M. Cain | Democracy is three wolves > > > http://www.druid.net/darcy/ | and a sheep voting on > > > +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. > > > > > ------------------------------------------------------------------------- > > > PyGreSQL Mailing List > > > Send requests to majordomo@vex.net > > ------------------------------------------------------------------------- > > PyGreSQL Mailing List > > Send requests to majordomo@vex.net > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > From mal@lemburg.com Thu Aug 26 08:48:01 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 26 Aug 1999 09:48:01 +0200 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected References: <199908251821.OAA12402@anvil.murkworks.com> Message-ID: <37C4F131.367574D2@lemburg.com> Brad Clements wrote: > > On 25 Aug 99, at 18:44, M.-A. Lemburg wrote: > > > I'd suggest setting the module level variable to the lowest > > level and then add a per connection attribute as you indicated. > > Ok. > > > When the cursor is created an implicit transactions start is > > performed. This is normal SQL behaviour. You don't need to do > > a .commit() to start a new transaction. > > True but, I need to tell ADO that I want to support transactions. If the > user never calls commit, how do I know that I should enable > transactions? If transactions are supported on the connection you should always enable them -- they are *very* useful to handle error conditions in DB code and not having them calls for an extra level in DB abstraction or other more direct means of restoring modified data. > > Auto-commit is enabled per default for ODBC. Since it renders > > ADO doesn't have to use ODBC, in fact I suspect most folks won't be > using the ODBC driver via ADO. > > The "Ole DB SQL Provider" and also, I think, the Oracle one, assume > that transactions are not used unless I turn them on. Hmm, seems to be a general MS style to run in auto-commit mode (not only for database connections ;). > If I just enable transactions, then do a BeginTransaction when issuing a > cursor, how do I know when to do a Commit() since auto-commit is > supposed to be disabled, and the user may never call > connection.commit()? Well basically, ADO should do all this for you. Here is what the ODBC docs say about transactions: """ Performing Transactions In auto-commit mode, every SQL statement is a complete transaction, which is automatically committed. In manual-commit mode, a transaction consists of one or more statements. In manual-commit mode, when an application submits an SQL statement and no transaction is open, the driver implicitly begins a transaction. The transaction remains open until the application commits or rolls back the transaction. """ Note that transactions are connection based, not cursor based. OTOH, the only way to do anything on a connection is by opening the first cursor. So the appropriate action would probably be to do the BeginTransaction call when the connection is created or when the first cursor is created. > > Make the .rollback() method dynamically defined, i.e. have it > > disabled on connections that do not support transactions. An explicit > > "begin transaction" is not needed since this always happens > > implicitly when you call connection.cursor() or cursor.commit()/ > > .rollback(). > > Er, well, I can't find in the 2.0 spec anywhere that it says that > constructing a new cursor automatically begins a transaction. It doesn't say this anywhere because SQL itself defines the behaviour. I have to correct myself here: opening a cursor does not *always* mean an implicit BeginTransaction. This is only true for the first cursor opened on the connection. And it's connection.commit()/ .rollback(), not cursor.commit()... wasn't my day yesterday, I guess. > My DA has to explicitely call the underlying begin, commit and rollback > as appropriate. Either I'm blind, or the DA 2.0 spec doesn't say enough > about transactions, automatic or otherwise, for me to know when I > should begin a new transaction. > > Can anyone point to archived discussion that talks about this subject, I > couldn't find any. I guess there wasn't any... Here is what I would suggest: ˇ if the datasource has transactions, put the connection into manual commit mode (otherwise stay in auto commit mode and disable the .rollback method) ˇ whenever opening a connection which does support transactions, do a BeginTransaction ˇ if the user closes a used connection without having done a .commit() or .rollback(), i.e. if there still is an open transaction, the interface should try to perform an implicit .rollback(); this is not necessary for auto commit mode connections Perhaps we should add a new section on this topic to a new 2.1 version of the DB API. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 128 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From ZakonS@eccelerate.com Thu Aug 26 14:10:06 1999 From: ZakonS@eccelerate.com (Zakon, Stuart) Date: Thu, 26 Aug 1999 09:10:06 -0400 Subject: [DB-SIG] FW: [PyGreSQL] DB API v2.0? Message-ID: Mark, If you have time that would be great! I'm new to the pygresql list so you should probably contact the list owner: D'Arcy J.M. Cain . My take is that the discussion should take place on db-sig@python.org since it is a move to the db api 2.0. Stuart > -----Original Message----- > From: Mark W. Alexander [SMTP:mwa@gate.net] > Sent: Wednesday, August 25, 1999 5:48 PM > To: Zakon, Stuart > Cc: db-sig@python.org > Subject: Re: [DB-SIG] FW: [PyGreSQL] DB API v2.0? > > Yes! > > I've been trying to find the time. I've got a fair amount of PyGreSQL > stuff that I wish was more portable. > > Let me know if this will be on db-sig or the PyGreSQL list. I'm > not currently on the PyGreSQL list. > > Mark Alexander > mwa@gate.net > > > On Wed, 25 Aug 1999, Zakon, Stuart wrote: > > > Date: Wed, 25 Aug 1999 12:54:26 -0400 > > From: "Zakon, Stuart" > > To: db-sig@python.org > > Subject: [DB-SIG] FW: [PyGreSQL] DB API v2.0? > > > > This is a thread forwarded from the PyGreSQL mailing list. > > We are polling for interest in doing a DB-API 2.0 interface to > PostgreSQL. > > Any interest out there? > > > > Stuart > > > From bkc@murkworks.com Thu Aug 26 14:23:16 1999 From: bkc@murkworks.com (Brad Clements) Date: Thu, 26 Aug 1999 09:23:16 -0400 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <37C4F131.367574D2@lemburg.com> Message-ID: <199908261316.JAA14142@anvil.murkworks.com> On 26 Aug 99, at 9:48, M.-A. Lemburg wrote: > Well basically, ADO should do all this for you. Here is what the > ODBC docs say about transactions: According to the Ole DB spec, handling of transactions is pretty much up to the DB provider. My interpretation is that I would get best results using explicit begin/commit calls. Again, I'm *not* targetting ODBC at all, though you *can* use ODBC via OLE DB, I suspect that would be uncommon since it's double layers. > Here is what I would suggest: > ˇ if the datasource has transactions, put the connection into > manual commit mode (otherwise stay in auto commit mode and > disable the .rollback method) > ˇ whenever opening a connection which does support transactions, > do a BeginTransaction > ˇ if the user closes a used connection without having done a .commit() > or .rollback(), i.e. if there still is an open transaction, > the interface should try to perform an implicit .rollback(); > this is not necessary for auto commit mode connections This sounds good but my problem with this is: 1. I call ADO.BeginTransaction when issuing a cursor 2. I would call ADO.CommitTrans if the user called connection.commit() 3. I would call ADO.RollbackTrans if the user called connection.rollback() 4. Since the 2.0 DB spec says "auto-commit must be initially disabled", then I'll never call ADO.CommitTrans unless the user calls connection.commit(). Therefore everything the user does on the connection is one huge transaction, right? Or, should I commit when the cursor object is destroyed? But you say perform a rollback if they didn't call commit. This is where my confusion lies. I need to support two types of users, those that don't know anything about transactions and hence won't call commit() (and wouldn't have called begintrans() if we had that function). And those that need explicit transaction control, such as for Zope 2. In Z2, I really do need to have an explicit begintrans, commit and rollback. > Perhaps we should add a new section on this topic to a new > 2.1 version of the DB API. ADO (aka Ole DB) has a ton of new stuff that could be very useful, though may be too specific to ms products. I think perhaps a clarification of how transactions are handled both when using, and not using connection.commit(). I'd also like to see a connection.begintrans() for completeness, though perhaps someone can show me how I've missed the boat on this issue entirely. I wouldn't doubt it. ;-) ps. I'll be working on the Zope 2 DA at the end of the week. I suspect I will find that I *must* have a connection.begintrans() implemented to support it. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From billtut@microsoft.com Thu Aug 26 14:35:58 1999 From: billtut@microsoft.com (Bill Tutt) Date: Thu, 26 Aug 1999 06:35:58 -0700 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not k nown until connected Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB91128@RED-MSG-50> > From: Brad Clements [mailto:bkc@murkworks.com] > > Perhaps we should add a new section on this topic to a new > > 2.1 version of the DB API. > > ADO (aka Ole DB) has a ton of new stuff that could be very useful, > though may be too specific to ms products. > Its all very useful and isn't specific at all, its just too much code to write in Unix land when you're not getting paid to do it. So moving OLE DB features into the Python DB API is something you really shouldn't worry about. Bill From pygresql@vex.net, db-sig@python.org Thu Aug 26 14:41:15 1999 From: pygresql@vex.net, db-sig@python.org (D'Arcy J.M. Cain) Date: Thu, 26 Aug 1999 09:41:15 -0400 (EDT) Subject: [DB-SIG] FW: [PyGreSQL] DB API v2.0? In-Reply-To: from "Zakon, Stuart" at "Aug 26, 1999 09:10:06 am" Message-ID: Thus spake Zakon, Stuart > Mark, > If you have time that would be great! > > I'm new to the pygresql list so you should probably contact the list owner: > D'Arcy J.M. Cain . I am also here. It doesn't matter to me where the discussion takes place. I just think it should be decided and stuck to so we don't have disjointed conversations because of people who are on one list and not the other. > My take is that the discussion should take place on db-sig@python.org since > it > is a move to the db api 2.0. Sounds reasonable. There are some very PyGreSQL specific issues so it could be argued the other way but it really doesn't matter that much. Are there people here who would rather that this discussion not take place on the db-sig list for any reason? -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. From petrilli@amber.org Thu Aug 26 15:16:16 1999 From: petrilli@amber.org (Christopher Petrilli) Date: Thu, 26 Aug 1999 10:16:16 -0400 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: ; from Andy Dustman on Wed, Aug 25, 1999 at 04:49:14PM -0400 References: <199908251821.OAA12402@anvil.murkworks.com> Message-ID: <19990826101616.A1452@amber.org> On Wed, Aug 25, 1999 at 04:49:14PM -0400, Andy Dustman wrote: > > In standard SQL, a transaction begins once you start executing SQL > statements (there's probably a more rigorous definition of this), and ends > when you execute COMMIT WORK or ROLLBACK WORK. There's no command that > explicitely begins a transaction. Well, this isn't entirely accurate :-) Sybase has a "begin transaction", and Oracle requires a "select for update" if you wish to do any form of locking. Otherwise, you're working in parallel versions and you're doing dirty reads. SQL is great for trivial things, but it's not that standard quite honestly. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright From mal@lemburg.com Thu Aug 26 15:05:49 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 26 Aug 1999 16:05:49 +0200 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected References: <199908261316.JAA14142@anvil.murkworks.com> Message-ID: <37C549BD.1B7980C9@lemburg.com> Brad Clements wrote: > > On 26 Aug 99, at 9:48, M.-A. Lemburg wrote: > > > Well basically, ADO should do all this for you. Here is what the > > ODBC docs say about transactions: > > According to the Ole DB spec, handling of transactions is pretty much > up to the DB provider. My interpretation is that I would get best results > using explicit begin/commit calls. > > Again, I'm *not* targetting ODBC at all, though you *can* use ODBC via > OLE DB, I suspect that would be uncommon since it's double layers. I'm just quoting ODBC stuff because that's where my main experience lies. I know of the many quirks that can happen to you in that area -- mxODBC has been out there for almost two years now. > > Here is what I would suggest: > > ˇ if the datasource has transactions, put the connection into > > manual commit mode (otherwise stay in auto commit mode and > > disable the .rollback method) > > ˇ whenever opening a connection which does support transactions, > > do a BeginTransaction > > ˇ if the user closes a used connection without having done a .commit() > > or .rollback(), i.e. if there still is an open transaction, > > the interface should try to perform an implicit .rollback(); > > this is not necessary for auto commit mode connections > > This sounds good but my problem with this is: > > 1. I call ADO.BeginTransaction when issuing a cursor No, you call it when you create the connection object to inplicitly start a new transaction. > 2. I would call ADO.CommitTrans if the user called connection.commit() > 3. I would call ADO.RollbackTrans if the user called connection.rollback() Right. > 4. Since the 2.0 DB spec says "auto-commit must be initially disabled", > then I'll never call ADO.CommitTrans unless the user calls > connection.commit(). Therefore everything the user does on the > connection is one huge transaction, right? No, you call CommitTrans when the user calls connection.commit() and RollbackTrans when he calls connection.close() or deletes the connection object. Plus, you call BeginTransaction after every call to connection.commit() and connection.rollback() to implicitly start a new transaction. > Or, should I commit when the cursor object is destroyed? But you say > perform a rollback if they didn't call commit. > > This is where my confusion lies. I need to support two types of users, > those that don't know anything about transactions and hence won't call > commit() (and wouldn't have called begintrans() if we had that function). > And those that need explicit transaction control, such as for Zope 2. In > Z2, I really do need to have an explicit begintrans, commit and rollback. Transaction control should be kept as simple as possible. This is what the standard SQL scheme implements -- you don't need an explicit begintransaction call. Believe me, it has worked for years like this ;-) > > Perhaps we should add a new section on this topic to a new > > 2.1 version of the DB API. > > ADO (aka Ole DB) has a ton of new stuff that could be very useful, > though may be too specific to ms products. > > I think perhaps a clarification of how transactions are handled both when > using, and not using connection.commit(). > > I'd also like to see a connection.begintrans() for completeness, though > perhaps someone can show me how I've missed the boat on this issue > entirely. I wouldn't doubt it. > > ;-) > > ps. I'll be working on the Zope 2 DA at the end of the week. I suspect I > will find that I *must* have a connection.begintrans() implemented to > support it. If you do, then something in the design of Zope DAs is broken. Providing an explicit .begintrans() method would introduce undefined processing states, e.g. connection.begintrans() c = connection.cursor() c.execute(...) del c connection.commit() # This is where the problem starts... c = connection.cursor() c.execute(...) # ... and this is where the problem ends :-) connection.begintrans() ... -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 127 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bkc@murkworks.com Thu Aug 26 23:14:41 1999 From: bkc@murkworks.com (Brad Clements) Date: Thu, 26 Aug 1999 18:14:41 -0400 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <37C549BD.1B7980C9@lemburg.com> Message-ID: <199908262208.SAA14758@anvil.murkworks.com> On 26 Aug 99, at 16:05, M.-A. Lemburg wrote: > > 4. Since the 2.0 DB spec says "auto-commit must be initially disabled", > > then I'll never call ADO.CommitTrans unless the user calls > > connection.commit(). Therefore everything the user does on the > > connection is one huge transaction, right? > > No, you call CommitTrans when the user calls connection.commit() > and RollbackTrans when he calls connection.close() or deletes > the connection object. So, if the user never calls connection.commit, then *all* his changes are one giant transaction? I must be a dunce. What's confusing me is that the spec says "auto- commit must be disabled", yet somehow you're saying I should auto- commit when he closes the connection. yet I thought you said I should rollback if he didn't call commit. How can a user use the my DB if they never call commit? (say, they're doing very simple stuff and don't think of it). Then I'll never call commit? I don't get it. Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From mal@lemburg.com Fri Aug 27 08:41:08 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 27 Aug 1999 09:41:08 +0200 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected References: <199908262208.SAA14758@anvil.murkworks.com> Message-ID: <37C64114.7C1175DA@lemburg.com> Brad Clements wrote: > > On 26 Aug 99, at 16:05, M.-A. Lemburg wrote: > > > > 4. Since the 2.0 DB spec says "auto-commit must be initially disabled", > > > then I'll never call ADO.CommitTrans unless the user calls > > > connection.commit(). Therefore everything the user does on the > > > connection is one huge transaction, right? > > > > No, you call CommitTrans when the user calls connection.commit() > > and RollbackTrans when he calls connection.close() or deletes > > the connection object. > > So, if the user never calls connection.commit, then *all* his changes are > one giant transaction? Right, if he never calls .commit() then all his changes are considered one transaction and even more: since the connection close invokes the .rollback() method he will never see his changes in the database (just a few days ago someone mailed me about such a "problem" with mxODBC). > I must be a dunce. What's confusing me is that the spec says "auto- > commit must be disabled", yet somehow you're saying I should auto- > commit when he closes the connection. yet I thought you said I should > rollback if he didn't call commit. Heh ? I said the close should do an implicit .rollback(). This is the safe way. An implicit .commit() could destroy data ! > How can a user use the my DB if they never call commit? (say, they're > doing very simple stuff and don't think of it). Then I'll never call commit? Right. Transactions are under user control and should not be committed automatically. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 127 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From bkc@murkworks.com Fri Aug 27 15:15:11 1999 From: bkc@murkworks.com (Brad Clements) Date: Fri, 27 Aug 1999 10:15:11 -0400 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <37C64114.7C1175DA@lemburg.com> Message-ID: <199908271408.KAA16352@anvil.murkworks.com> On 27 Aug 99, at 9:41, M.-A. Lemburg wrote: > > How can a user use the my DB if they never call commit? (say, they're > > doing very simple stuff and don't think of it). Then I'll never call commit? > > Right. Transactions are under user control and should not > be committed automatically. I think we are getting somewhere. You said: 1. When issuing a cursor, I should call the underlying ADO.BeginTrans 2. I should never auto-commit, so the user must call connection.commit() 3. If the user never calls commit, I'll rollback all of their changes when they close the connection object 4. Hence, users that never call commit(), can not really use the DB because none of their changes will ever be saved. Is this correct? Should I therefore assume that all DB users will ALWAYS call connection.commit (or rollback), and that NO ONE will ever try to use the DB without using connection.commit? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From lhonda@zip.net Fri Aug 27 15:41:48 1999 From: lhonda@zip.net (Luiz Tadao Honda) Date: Fri, 27 Aug 1999 11:41:48 -0300 Subject: [DB-SIG] Where can I find some DCOracle examples? Message-ID: <37C6A3AC.B6B46322@zip.net> Hi! The subject says all. 8-) tks in advance. l.t.honda From hernan.foffani@iname.com Fri Aug 27 16:53:35 1999 From: hernan.foffani@iname.com (=?iso-8859-1?Q?Hern=E1n_Mart=EDnez_Foffani?=) Date: Fri, 27 Aug 1999 12:53:35 -0300 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <199908271408.KAA16352@anvil.murkworks.com> Message-ID: <000001bef0a4$51feabe0$5401010a@pez-volador> To get things right (or to add confusion... :-) [we: specific DB module developers. users: programmers calling DBApis from their python app] A) IF the DBMS requires explicit "Begin Transaction" 1. we should call BeginTransaction when the connection object is created. 2. we should call BeginTransaction after every Commit or RollbackTransaction. 3. we should call RollbackTransaction when closing/deleting the connection object. B) IF the DBMS does not require explicit "Begin Transaction" 1. we should call RollbackTransaction when closing/deleting the connection object. Being A3 and B1 worth for sanity reasons. In this way users doesn´t have to special things, and the same program works across implementations. The DBApi follows ANSI SQL in this aspect which, as Marc-Andre wrote, "you are always inside a transaction". The "Begin Transaction" issue was "raised" by DBMS because they try to "save" resources (transaction processing is expensive) If users try to "save resources" then they must turn AutoCommit ON. In this mode users doesn't use explicit Commit or Rollback methods. For Brad now, > I think we are getting somewhere. > > You said: > > 1. When issuing a cursor, I should call the underlying ADO.BeginTrans NO, when creating the connection object. BUT, I don´t know ADO! > 2. I should never auto-commit, so the user must call > connection.commit() YES. > 3. If the user never calls commit, I'll rollback all of their > changes when > they close th connection object You ALLWAYS rollback when closing. If the user had previously commited, DBMS won't rollback any transaction. > > 4. Hence, users that never call commit(), can not really use the DB > because none of their changes will ever be saved. well, they CAN use it. As a matter of fact it is a trick that many programmers, me included, use: You can "try and see (and time!)" different algorithms in production environment safely. > > Is this correct? Should I therefore assume that all DB users will > ALWAYS call connection.commit (or rollback), and that NO ONE will > ever try to use the DB without using connection.commit? Don't forget that users can turn AutoCommit ON. Regards, Hernán. PS. Hope I got it right! From bkc@murkworks.com Fri Aug 27 17:54:21 1999 From: bkc@murkworks.com (Brad Clements) Date: Fri, 27 Aug 1999 12:54:21 -0400 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <000001bef0a4$51feabe0$5401010a@pez-volador> References: <199908271408.KAA16352@anvil.murkworks.com> Message-ID: <199908271647.MAA16524@anvil.murkworks.com> On 27 Aug 99, at 12:53, Hernán Martínez Foffani wrote: > > 4. Hence, users that never call commit(), can not really use the DB > > because none of their changes will ever be saved. > well, they CAN use it. As a matter of fact it is a trick that many > programmers, me included, use: You can "try and see (and time!)" > different algorithms in production environment safely. > > > > > Is this correct? Should I therefore assume that all DB users will > > ALWAYS call connection.commit (or rollback), and that NO ONE will > > ever try to use the DB without using connection.commit? > Don't forget that users can turn AutoCommit ON. Ok, I see. If they don't turn on auto-commit, and if they don't call connection.commit, then their changes are rolled back when closing the connection. But .. the mechanism to enable auto-commit is not documented in the DB spec. Should a standard be defined for 2.1 of the spec? Brad Clements, bkc@murkworks.com (315)268-1000 http://www.murkworks.com (315)268-9812 Fax netmeeting: ils://ils.murkworks.com ICQ: 14856937 From hernan.foffani@iname.com Fri Aug 27 22:18:45 1999 From: hernan.foffani@iname.com (=?iso-8859-1?Q?Hern=E1n_Mart=EDnez_Foffani?=) Date: Fri, 27 Aug 1999 18:18:45 -0300 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected In-Reply-To: <199908271647.MAA16524@anvil.murkworks.com> Message-ID: <000101bef0d1$bec70e20$5401010a@pez-volador> > -----Original Message----- > From: db-sig-admin@python.org On Behalf Of Brad Clements > > > Ok, I see. If they don't turn on auto-commit, and if they don't call > connection.commit, then their changes are rolled back when closing the > connection. > > But .. the mechanism to enable auto-commit is not documented in the > DB spec. Should a standard be defined for 2.1 of the spec? > May be. But the DB-API is very terse on porpouse (sp?). We should target all major DBMS first. -Hernán From mal@lemburg.com Sat Aug 28 15:16:36 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 28 Aug 1999 16:16:36 +0200 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected References: <199908271408.KAA16352@anvil.murkworks.com> Message-ID: <37C7EF44.61D74FCE@lemburg.com> Brad Clements wrote: > > On 27 Aug 99, at 9:41, M.-A. Lemburg wrote: > > > > How can a user use the my DB if they never call commit? (say, they're > > > doing very simple stuff and don't think of it). Then I'll never call commit? > > > > Right. Transactions are under user control and should not > > be committed automatically. > > I think we are getting somewhere. > > You said: > > 1. When issuing a cursor, I should call the underlying ADO.BeginTrans Only for the first cursor created for a connection. You might as well do the call when the connection is created, if that is possible with ADO semantics (this may need a cursor). > 2. I should never auto-commit, so the user must call > connection.commit() Right. > 3. If the user never calls commit, I'll rollback all of their changes when > they close the connection object > > 4. Hence, users that never call commit(), can not really use the DB > because none of their changes will ever be saved. Sure they can: all SELECTs will work just fine. You can think of a non-commit session as a read-only session. > Is this correct? Should I therefore assume that all DB users will > ALWAYS call connection.commit (or rollback), and that NO ONE will > ever try to use the DB without using connection.commit? Nope. People can use SELECT and other queries not involving changes to the data store without ever thinking about transactions, so connections without an explicit call to connection.commit() are useful too. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 127 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Sat Aug 28 15:44:06 1999 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 28 Aug 1999 16:44:06 +0200 Subject: [DB-SIG] Python 2.0 DB Api - Threading and Transactions not known until connected References: <199908271408.KAA16352@anvil.murkworks.com> <199908271647.MAA16524@anvil.murkworks.com> Message-ID: <37C7F5B6.79911BC@lemburg.com> Brad Clements wrote: > > On 27 Aug 99, at 12:53, Hernán Martínez Foffani wrote: > > > > 4. Hence, users that never call commit(), can not really use the DB > > > because none of their changes will ever be saved. > > well, they CAN use it. As a matter of fact it is a trick that many > > programmers, me included, use: You can "try and see (and time!)" > > different algorithms in production environment safely. > > > > > > > > Is this correct? Should I therefore assume that all DB users will > > > ALWAYS call connection.commit (or rollback), and that NO ONE will > > > ever try to use the DB without using connection.commit? > > Don't forget that users can turn AutoCommit ON. > > Ok, I see. If they don't turn on auto-commit, and if they don't call > connection.commit, then their changes are rolled back when closing the > connection. > > But .. the mechanism to enable auto-commit is not documented in the > DB spec. Should a standard be defined for 2.1 of the spec? The 2.0 spec says that connections may provide a method to control auto-commit. Nothing more. I don't think that the spec should really go into details here, because auto-commit and transaction handling in general are database specific (e.g. there are quite a few different transaction isolation levels which a data source can implement). -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 127 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/