> On 28 Oct 2022, at 18:14, Marc-Andre Lemburg <m...@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 _______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
