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
> (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. 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).
In SQLAlchemy, we expose "autocommit" through a method that expects that IO may
occur, so we aren't affected by the decision here. We absolutely raise an
error if someone is attempting to modify the "autocommit" status, as well as
the isolation level, mid-transaction - this indicates a lack of clear intent on
the part of the user, and if there's one thing I've learned in the past 16
years of doing Python it's that it definitely is better to raise when the user
does something which does not seem to have a clear rationale - the user is
likely confused and would do better to have some guardrails let them know as
such, rather than guessing and doing something silently. The latter behavior
is how we get angry bug reports from someone who spent hours/days/weeks trying
to understand some unexpected behavior and found it based on implicit decisions
that came from the user's original mis-configurations.
This is absolutely not the kind of culture you see in MSFT C APIs, where a
decidedly different kind of programmer will pore over every line of documents
like the one you link and will invoke such methods with deep caution.
In SQLAlchemy, we consider "autocommit" to be one of several "isolation level"
choices, which may be seen as more of an "ACID level" setting. A block of code
that raises looks like:
from sqlalchemy import create_engine, text
e = create_engine("postgresql://scott:tiger@localhost/test")
with e.begin() as conn:
conn.execute(text("insert into table (x) values ('foo')"))
# raises. what legitimate reason would there be for the
# user to call this in the middle of a transaction?
conn.execution_options(isolation_level="AUTOCOMMIT")
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.
>
> > 3. We leave these semantics open and up to the database module
> > to determine.
> >
> > My preference would be option 2, since this makes things clear for
> > everyone and is intuitive (well, at least for me :-)).
>
> --
> 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
>
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
https://mail.python.org/mailman/listinfo/db-sig
