[DB-SIG] autocommit support in pep-249

M.-A. Lemburg mal at egenix.com
Wed Sep 14 20:18:06 CEST 2011


Chris Clark wrote:
> M.-A. Lemburg wrote:
>> Chris Clark wrote:
>>  
>>> Hi All,
>>>
>>> I was discussing with someone today autocommit support and found an area
>>> of pep-249 where I think we could improve the wording (and the spec):
>>>
>>> http://www.python.org/dev/peps/pep-0249/
>>>
>>> .....
>>>
>>>        .commit()
>>>                     Commit any pending transaction to the database. Note
>>> that
>>>            if the database supports an auto-commit feature, this must
>>>            be initially off. An interface method may be provided to
>>>            turn it back on.
>>>
>>> .....
>>>
>>> It is the last sentence that I'm looking at:
>>>
>>>    
>>>> An interface method may be provided to turn it back on.
>>>>       
>>> Comments:
>>>
>>>    * The "may" clearly marks this as an optional interface (and I'm
>>>      happy about that).
>>>    * It would be helpful to make clear what the interface method would
>>>      be so module authors can implement this consistently
>>>    * if autocommit can be turned on in a connection, there should have
>>>      a way to turn it off again
>>> ...
>>> Comments?
>>>     
>>
>> mxODBC and mxODBC Connect will support a writable connection
>> attribute connection.autocommit to turn the feature on/off.
>> This works by assigning a boolean to the attribute. The
>> attribute also allows for an easy way to check whether autocommit
>> is active or not.
>>
>> They both already support doing this via the (non-standard) DB-API
>> extension connection.setconnectoption() method.
>>
>> From an API perspective, using an attribute is the right
>> and user-friendly approach. My only gripe with this is the fact,
>> that querying or setting the attribute can cause exceptions,
>> which you'd normally only expect from function/method calls.
>>
>> Other than that I'm +1 on adding the attribute as standard
>> DB-API 2.0 extension.
>>
>>   
> 
> Thanks M.A..
> 
> It looks like we are heading towards a consensus on an exception being
> used (when mid transaction and autocommit on is requested). So we should
> document that, I'm inclined to be a little whishy-washy and have a short
> line along the lines of:
> 
>    If an attempt is made to enable autocommit mid transactions this is
> likely to cause a DBI exception, the exception raised may vary between
> drivers/backends but will be a sub-class of driver.Error.

I actually like the way ODBC handles these cases:

* Turning on autocommit has the same effect as doing a .commit()
and then proceeding in autocommit mode.

* Turning off autocommit causes a new transaction to start.

but I guess we cannot require this from database modules, since
the semantics are usually defined by the database backend and not
the client lib or driver.

> I'd like to try and cover the case mentioned above, where "*querying* or
> setting the attribute can cause exceptions". Is this likely? If so we
> should document that with a one liner too.

It's not likely, but can happen, e.g. if the connection to the
database is lost or the database doesn't support transactions or
if the backend doesn't support transactions (turning autocommit
off would then raise an exception).

> I'd like to steal your wording for documentation, I've only changed the
> first few words:
> 
> ---------
> A connection may optionally support a writable connection
> attribute connection.autocommit to turn the feature on/off.
> This works by assigning a boolean to the attribute. The
> attribute also allows for an easy way to check whether autocommit
> is active or not.
> 
> If an attempt is made to enable autocommit mid transactions this is
> likely to cause a DBI exception, the exception raised may vary between
> drivers/backends but will be a sub-class of driver.Error. A driver may
> choose to implement autocommit manually (that is, manually issue commits
> at the end of each cursor operation), to raise an exception if mid
> transaction, or pass the autocommit request to the backend and raise an
> exception for errors that the backend raises.
> ---------

I'm not sure about that last paragraph. The exception raising
part should really just be about turning autocommit on/off, not about
the way exceptions are raised as a result of the autocommit
implementation during cursor operations.

> It may be that we have more discussion on the commit/rollback options
> but I'm not planning on raising those options again unless there is
> interest from other posters.
>
> RE the conn.begin() that is a -1 from me, this seems like a separate
> item to autocommit and may deserve a new thread. This doesn't prevent
> implementers from adding a non-standard exception though if it will
> prove to be useful for some users.

Agreed.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 14 2011)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2011-10-04: PyCon DE 2011, Leipzig, Germany                20 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


More information about the DB-SIG mailing list