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

[Tony Locke]

Hello all, with pg8000 if autocommit is turned on while a transaction is in
progress, the autocommit behaviour only takes effect after the current
transaction has been explicitly committed or rolled back. Of the options
given, I'd go for option 1, raising an exception. I don't like the idea of
SQL statements being executed implicitly, which is why I'd be against
option 2.

A radical suggestion for DBAPI-3.0 would be to remove autocommit
completely. I think this would make the dbapi interface easier for people
to understand, because there would be no implicit SQL commands, which is
what I think confuses people. Of course the downside is less portability,
but I think people accept that if they change their database a lot of
things will be different, and autocommit is just one of them. A higher
level library such as SQLAlchemy could still emit the correct SQL via the
dialect so that users of SQLAlchemy wouldn't need to know about autocommit.

Regards,

Tony.

On Wed, 2 Nov 2022 at 06:08, Erlend Egeberg Aasland <erlenda at gmail.com>
wrote:

>
> On Tue, 1 Nov 2022 at 14:37, Marc-Andre Lemburg <mal at egenix.com> wrote:
>
>> […] Instead, I believe we should document what many modules already
>> implement, which is the read/write .autocommit attribute. As for semantics,
>> we should probably go with option 3 and only mention that many modules will
>> actually already implement option 2.
>>
> +1
>
> Regarding the problem with having attribute write access result in
>> possible I/O, I think we should at the same time deprecate the write nature
>> of the .autocommit attribute and announce that it'll be replaced with a
>> newmethod, e.g. .setautocommit() (the DB-API has traditionally not added
>> underscores to the names, except for the optional TPC API group), for
>> DB-API 3.0.
>>
> For the upcoming autocommit attribute of the stdlib sqlite3 module, I
> wonder if we should stick with these conventions right from the start. That
> is, autocommit can either be set from the connection constructor (using the
> new autocommit property), or using a setautocommit() method. The autocommit
> attribute will be read-only.
>
> Related to this, I'd also suggest adding a new keyword parameter to the
>> connection constructor (autocommit), which defaults to False and can be
>> used to create autocommit connections right from the start.
>>
> +1
>
>
> Erlend
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> https://mail.python.org/mailman/listinfo/db-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/db-sig/attachments/20221103/33b91e8b/attachment.html>