[DB-SIG] Adding Connection.autocommit as standard extension to DB-API 2.0 (PEP 249)
Mike Bayer
mike_mp at zzzcomputing.com
Tue Nov 1 09:03:20 EDT 2022
On Sun, Oct 30, 2022, at 5:38 PM, Erlend Egeberg Aasland wrote:
>
> > 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
I checked JDBC and it also follows this convention: https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setAutoCommit(boolean)
*however*, in both cases of ODBC and JDBC, these are function calls. If DBAPI had a connection method define called `set_autocommit()`, the implicit COMMIT would be fine. In Python, running an attribute set operation should not incur IO at the point at which the attribute is being assigned. So if we are following existing standards from different programming languages, the .autocommit attribute should be changed to be a method `set_autocommit()`.
>
> 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.
this is the only variant of the proposal that would be a breaking change for SQLAlchemy, since it removes existing functionality that most DBAPIs have now and change a use case that is now possible to be one that is impossible. The reality would be that some would comply, and others (most others) would not, because it is extremely difficult (and mostly unnecessary) to remove functionality from an API. It's also inconsistent with the previous notion of following other existing database standards as both ODBC and JDBC feature means of affecting the autocommit behavior on an already opened connection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/db-sig/attachments/20221101/65d13d38/attachment.html>
More information about the DB-SIG
mailing list