[DB-SIG] Adding Connection.autocommit as standard extension to DB-API 2.0 (PEP 249)

[Erlend Egeberg Aasland]

> On 28 Oct 2022, at 18:14, Marc-Andre Lemburg <mal at egenix.com> wrote:
> 
> On 28.10.2022 16:51, Mike Bayer wrote:
>> On Fri, Oct 28, 2022, at 10:20 AM, Marc-Andre Lemburg wrote:
>>> On 28.10.2022 15:58, Marc-Andre Lemburg wrote:
>>> > If there is a pending transaction, though, there are three approaches
>>> > we could take:
>>> >
>>> > 1. The database module raises an exception, to force an explicit
>>> >     .commit() or .rollback() by the programmer.
>>> >
>>> > 2. The module automatically commits the pending transaction,
>>> >     since that's what autocommit is all about.
>>> 
>>> Just checked: Option 2 is what ODBC mandates...
>>> https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlsetconnectattr-function <https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlsetconnectattr-function>
>>> (search for SQL_ATTR_AUTOCOMMIT)
>> That's a C API, which has different programming conventions than what Python has, and it's also referring towards a function that's being called, so while that's a datapoint to note, I dont think by itself it really indicates how a Python API should organize itself one way or the other. 
> 
> I just wanted to note that the semantics of what to do when switching
> from False to True are already defined in one of the major database
> APIs standards, so it's good practice to follow such a standard.

+1

My preference would be 2. or 3.

> Overall, I believe that important settings such as autocommit
> should only be set in the connection constructor, since the
> semantics change dramatically between autocommit and manual
> commit.
> 
> In such a world, we'd only have an autocommit keyword argument
> in the Connection constructor and a read-only attribute on the
> object to query this after creation.

I would be ok with that.


Erlend