(I missed replying to the group. --- buggy mental code path ...;)<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Vernon Cole</b> <span dir="ltr"><<a href="mailto:vernondcole@gmail.com">vernondcole@gmail.com</a>></span><br>
Date: Thu, Sep 15, 2011 at 4:23 AM<br>Subject: Re: [DB-SIG] autocommit support in pep-249<br>To: Federico Di Gregorio <<a href="mailto:fog@dndg.it">fog@dndg.it</a>><br><br><br><br><br><div class="gmail_quote"><div>
<div>
</div><div class="h5">On Wed, Sep 14, 2011 at 6:16 AM, Federico Di Gregorio <span dir="ltr"><<a href="mailto:fog@dndg.it" target="_blank">fog@dndg.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[snap]<br>
<br>
Client code can set .autocommit (yes, I am +1 for the attribute) to true<br>
by two different code paths: the "correct" one and the "buggy" one. The<br>
correct code path is not a problem: as long as the programmer knows the<br>
behaviour she can do the right thing:<br>
<br>
1. exception => make sure to commit() or rollback() before,<br>
depending on the wanted outcome;<br>
2. commit => rollback() if you don't want to commit changes,<br>
do nothing in the other case;<br>
3. rollback => as (2), reversed.<br>
<br>
What I am interested in is the behaviour of the driver when the code<br>
sets .autocommit to true following a buggy code path, i.e., when there<br>
is a pending transaction and the code is unaware of it:<br>
<br>
1. exception => pending transaction is lost, user (and eventually<br>
also the programmer) gets a stack trace: this is<br>
good because the user is sure about the outcome (data<br>
is lost) _and_ has information about the problem;<br>
2. commit => pending transaction is commited but it is what the<br>
code was really supposed to do? noboby will know until<br>
someone peeks at the database and _then_ a possibly<br>
difficult bug hunting session begins;<br>
3. rollback => as (2), but data is lost.<br>
<br>
Having commit or rollbacks happen because of a bug really scares me:<br>
spurious data starts to popup into the database and finding the bugs<br>
usually isn't a piece of cake. That's why I vote for the exception.<br>
<br>
federico<br>
<br></blockquote></div></div><div>It's those buggy code paths that we are discussing, and I am much more interested in doing the right thing on a good code path. We're using Python here, not Pascal. If I wanted to force all programmers to be perfect, I'ld require that all variables be declared. What we are discussing here is what to do in a situation which a wise programmer will never get in to. I don't want to waste a lot of time and a lot of code making sure that the results of poor programming are consistent between different database engines. I would advocate that the results of this questionable practice should be explicitly left as "undefined", with the cautionary note that an exception MIGHT occur, and suggest that the application programmer should either commit or rollback any in-progress transactions before changing the value of autocommit. <br>
<br> That way no complicated parsing or state tracking is required. My __setattr__ for .autocommit would simply pass the new value on to the ADO engine to do whatever it pleased with it -- and pass back any error which the engine might decide to return.<br>
<br>I LIKE simple -- it usually works better.<br><font color="#888888">--<br>Vernon<br><br></font></div></div>
</div><br>