I've thought some more about this over the last couple of days.
Since we're adding a standard extension to the DB-API 2.0 based on
existing use in the wild, we should really stick to what database module
authors have implemented and not propose new semantics or add anything
which is not yet widely accepted to the 2.0 version.
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.
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 new method, 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.
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.
For the next version of the DB-API we should then also consider async
methods and functions and try to make sure that all important API parts
can be used in an async manner, in particular, making sure that API
parts which can result in I/O are always defined in form of methods or
functions (I believe that most are already, except for the .autocommit
attribute which many modules implement).
More generally speaking, I think Python is missing async support for
properties. Perhaps this will be added at some point, so that we can
write e.g.
await connection.autocommit = True
OTOH, I'm not really a fan of complex properties and even less so, ones
which can result in I/O.
I'll put together a new proposal for the new standard extension,
addressing the above.
On 01.11.2022 14:03, Mike Bayer wrote:
On Sun, Oct 30, 2022, at 5:38 PM, Erlend Egeberg Aasland wrote:
> 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
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.
_______________________________________________
DB-SIG maillist -DB-SIG@python.org
https://mail.python.org/mailman/listinfo/db-sig
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Nov 01 2022)
Python Projects, Coaching and Support ... https://www.egenix.com/
Python Product Development ... https://consulting.egenix.com/
________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
https://mail.python.org/mailman/listinfo/db-sig
