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: <Pine.LNX.4.10.9908020019200.12056-100000@kenny.comstar.net>

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
<snip>

# 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: <Pine.LNX.4.10.9908101330110.863-100000@kenny.comstar.net>

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hello,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>We are attempting to install DCOracle on our IBM RS/6000 under AIX =
</DIV>
<DIV>with numerous unresolved problems.&nbsp; We&nbsp;want  to be able =
to=20
connect</DIV>
<DIV>to our Oracle-8.0.5 database with Python-1.5.2. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Has anyone experienced this combination of elements in an=20
installation?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Your input would be greatly appreciated!</DIV>
<DIV>&nbsp;</DIV>
<DIV>TIA</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Larry Greene</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_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: <Pine.LNX.4.10.9908101330110.863-100000@kenny.comstar.net>
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: <Pine.LNX.4.10.9908121002330.28988-100000@kenny.comstar.net>

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: <Pine.LNX.4.10.9908162354150.18923-100000@mjordan.hq.primeon.com>

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: <B9AA1D5DA95ED211900100805F6FFF9C017DA5C5@exbhbhmb01.us.dbisna.com>

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 <darcy@{druid|vex}.net>   |  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: <Pine.LNX.4.10.9908251644240.18316-100000@kenny.comstar.net>

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: <B9AA1D5DA95ED211900100805F6FFF9C017DA5C5@exbhbhmb01.us.dbisna.com>
Message-ID: <Pine.A41.4.03.9908251745430.27724-100000@dakota.gate.net>

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" <ZakonS@eccelerate.com>
> 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 <darcy@{druid|vex}.net>   |  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: <B9AA1D5DA95ED211900100805F6FFF9C017DA8D7@exbhbhmb01.us.dbisna.com>

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 <darcy@{druid|vex}.net>.

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" <ZakonS@eccelerate.com>
> > 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: <B9AA1D5DA95ED211900100805F6FFF9C017DA8D7@exbhbhmb01.us.dbisna.com> from "Zakon, Stuart" at "Aug 26, 1999 09:10:06 am"
Message-ID: <m11JzmG-0000bFC@druid.net>

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 <darcy@{druid|vex}.net>.

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 <darcy@{druid|vex}.net>   |  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: <Pine.LNX.4.10.9908251644240.18316-100000@kenny.comstar.net>; from Andy Dustman on Wed, Aug 25, 1999 at 04:49:14PM -0400
References: <199908251821.OAA12402@anvil.murkworks.com> <Pine.LNX.4.10.9908251644240.18316-100000@kenny.comstar.net>
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/