[DB-SIG] autocommit support in pep-249

Chris Clark Chris.Clark at ingres.com
Tue Sep 13 18:39:21 CEST 2011


Vernon Cole wrote:
>> Properties are just the right tools for this
>> task, and appear to be the most used solution in popular drivers.
>>
>>     
> I think that term "attributes" is more commonly used, rather than
> "properties", but I agree completely.
> "conn.autocommit = True" seems pythonic, as does "if not
> conn.autocommit".   Getters and Setters feel like java. The
> implementing programmer has getattr and setattr for exactly that
> purpose, and the calling programmer has a clean interface.
>   

Property is the correct name for this in Python, see 
http://docs.python.org/library/functions.html

I agree using a property is a good idea, very easy to document and use. 
If/when I get around to it ;-) that is the route I'll take with jyjdbc.

>> The behaviour of setting autocommit when a transaction is already open
>> is also to be seen: there are three basic option:
>>
>> - have a commit
>> - have a rollback
>> - have an error
>>
>> I feel the implicit commit is the most dangerous option. An implicit
>> rollback may be more acceptable (it's the same behaviour of closing
>> the connection with a transaction in progress): I proposed it for
>> psycopg but, in the discussion, raising an exception proved the most
>> popular option.
>>
>>     
> I don't think I know how to even determine whether there is a
> transaction in progress in ADO.(*)  If there is a way, then checking
> on it just so that I can raise an exception seems expensive.  Remember
> that most of the time the resulting stack trace would not be seen by
> the programmer who goofed up, but a completely innocent user -- and to
> her it looks like the program just crashed for no reason.  The
> rollback would be easy to program and user friendly.  I vote rollback.
>   

The exception route has the potential to be the easiest for most DBMS 
implementations, most DBMSs will raise an error, so the driver doesn't 
need to track state and can just propagate the DBMS error. For some 
backends, state tracking would be required which is why I suggested the 
"easy" commit option. Rollback seems semi safe BUT when setting 
autocommit to ON the default behavior of a rollback seems a little 
surprising.

I'm not in love with committing when the autocommit state is changed but 
for the "enable auto commit" operation it seems logical, the user is 
requesting commits take place under the covers. Conversely when 
disabling autocommit (after it has previously been enabled) we are 
either not in a transaction (due to auto commit being on) or we could 
still be fetching mid select, in which case a commit would be the same 
as  a rollback. I.e. only impact on locking, any writes to the database 
would have been already auto committed.

So I think we have 3 people each advocating slightly different options 
for what to do when changing auto commit options :-)

   1. exception
   2. commit
   3. rollback


I'll be happy with what ever we as a group decide (so long as we 
document it), I think committing will be least surprising for end users, 
so whilst I'm not keen on it I feel I should champion it.

Are people happy with this rough approach (we can thrash out 
exception/rollback/commit) where this is an optional extension, i.e. not 
required?

Chris



More information about the DB-SIG mailing list