(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">&lt;<a href="mailto:vernondcole@gmail.com">vernondcole@gmail.com</a>&gt;</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 &lt;<a href="mailto:fog@dndg.it">fog@dndg.it</a>&gt;<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">&lt;<a href="mailto:fog@dndg.it" target="_blank">fog@dndg.it</a>&gt;</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 &quot;correct&quot; one and the &quot;buggy&quot; 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 =&gt; make sure to commit() or rollback() before,<br>
                  depending on the wanted outcome;<br>
  2. commit    =&gt; rollback() if you don&#39;t want to commit changes,<br>
                  do nothing in the other case;<br>
  3. rollback  =&gt; 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 =&gt; 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    =&gt; 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  =&gt; 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&#39;t a piece of cake. That&#39;s why I vote for the exception.<br>
<br>
federico<br>
<br></blockquote></div></div><div>It&#39;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&#39;re using Python here, not Pascal.  If I wanted to force all programmers to be perfect, I&#39;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&#39;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 &quot;undefined&quot;, 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>