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 <erle...@gmail.com> wrote: > > On Tue, 1 Nov 2022 at 14:37, Marc-Andre Lemburg <m...@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@python.org > https://mail.python.org/mailman/listinfo/db-sig >
_______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
