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.
As I indicated before, if we were writing an asyncio DBAPI
spec, doing any kind of IO on an attribute set would be a non-starter;
IO under asyncio always requires an awaitable function is called.
I think option 2 is probably what most DBAPIs would do anyway and they
probably do now (we should maybe check what the current practice is
among some of the current implementations).
That would be my guess as well. I know that mxODBC used to do
option 2 (simply as the result of ODBC mandating this).
[...]
>
I think if we wanted to cover what "Pythonisms" are crossed by option 1
or 2, I can think of a bunch as follows:
"In the face of ambiguity, refuse the temptation to guess." - option 1 wins
"dont do IO on attribute set operations" - option 1 wins
"Explicit is better than implicit." - option 1 wins
This is all strictly 2 cents on my part, DBAPIs are already doing
whatever they're going to do in this area and my own libraries are ready
for whatever.
I agree that a method would be better for this, e.g.
.set_autocommit(True/False)
Something else we could do (*):
Only define .autocommit for reading in the DB-API and add a new
standard extension to adjust the setting via a method. I'd still
favor the option 2 semantics for the new method. Because it's
a new method, we could clearly define the behavior and avoid all
guessing.
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.
Such a change could be implemented for a DB-API 3.0. For 2.0,
the ship has sailed already.
So how about going with the above compromise (*) ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Oct 28 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
