Re: Adding Connection.autocommit as standard extension to DB-API 2.0 (PEP 249)
"Mike Bayer" <[email protected]> Fri, 28 Oct 2022 10:14:54 -0400
| Newsgroups | gmane.comp.python.db |
|---|---|
| Message-ID | <[email protected]> |
--===============4190027365797030491==
Content-Type: multipart/alternative;
boundary=50dc3cb7d1614c15bcc29998cedf84c1
--50dc3cb7d1614c15bcc29998cedf84c1
Content-Type: text/plain
On Fri, Oct 28, 2022, at 10:06 AM, Marc-Andre Lemburg wrote:
> On 28.10.2022 16:02, Mike Bayer wrote:
> >
> >
> > On Fri, Oct 28, 2022, at 9:58 AM, 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.
> >>
> >> 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 :-)).
> >
> > option 3 is likely what will occur in practice. it feels a little
> > awkward for an attribute set operation to move forward with a
> > transactional modification to the database server.
>
> Think of this as a property, which is how many database modules
> will implement it.
>
> I agree that it feels a bit awkward, especially since setting
> an attribute should normally not cause exceptions, but it's become
> a standard among modules nonetheless (I don't remember who started
> with it).
well, an exception saying, "I'm not going to commit the transaction here, please call commit() or rollback() first" is of much narrower scope than one that went all the way out to the database to commit a transaction, which then failed. Or worse, some routine that sets .autocommit as a matter of course ends up causing network round trips in an unexpected place.
I think the bigger issue here is that this proposes allowing network IO to occur by setting an attribute. I know this is of course *possible* but this is not considered to be a good practice, particularly in the age of asyncio (which I know, DBAPI is not asyncio, but these things still have interactions in practice).
The precedent however is that DBAPIs take lots of liberties with things whether the DBAPI spec allows them to or not.
--50dc3cb7d1614c15bcc29998cedf84c1
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Fri, Oct 28, 2022, at 10:06 AM, Marc-Andre Lemburg wro=
te:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>On 28.1=
0.2022 16:02, Mike Bayer wrote:<br></div><div>> <br></div><div>&=
gt; <br></div><div>> On Fri, Oct 28, 2022, at 9:58 AM, Marc-Andr=
e Lemburg wrote:<br></div><div>>> If there is a pending transactio=
n, though, there are three approaches<br></div><div>>> we could ta=
ke:<br></div><div>>><br></div><div>>> 1. The database module=
raises an exception, to force an explicit<br></div><div>>> =
.commit() or .rollback() by the programmer.<br></div><div>&=
gt;><br></div><div>>> 2. The module automatically commits the p=
ending transaction,<br></div><div>>> since that=
's what autocommit is all about.<br></div><div>>><br></div><div>&g=
t;> 3. We leave these semantics open and up to the database module<br=
></div><div>>> to determine.<br></div><div>>=
><br></div><div>>> My preference would be option 2, since this =
makes things clear for<br></div><div>>> everyone and is intuitive =
(well, at least for me :-)).<br></div><div>> <br></div><div>>=
option 3 is likely what will occur in practice. it feels a =
little <br></div><div>> awkward for an attribute set operation t=
o move forward with a <br></div><div>> transactional modificatio=
n to the database server.<br></div><div><br></div><div>Think of this as =
a property, which is how many database modules<br></div><div>will implem=
ent it.<br></div><div><br></div><div>I agree that it feels a bit awkward=
, especially since setting<br></div><div>an attribute should normally no=
t cause exceptions, but it's become<br></div><div>a standard among modul=
es nonetheless (I don't remember who started<br></div><div>with it).<br>=
</div></blockquote><div><br></div><div><br></div><div>well, an exception=
saying, "I'm not going to commit the transaction here, please call comm=
it() or rollback() first" is of much narrower scope than one that went a=
ll the way out to the database to commit a transaction, which then faile=
d. Or worse, some routine that sets .autocommit as a matter =
of course ends up causing network round trips in an unexpected place.&nb=
sp; <br></div><div><br></div><div>I think the bigger issue h=
ere is that this proposes allowing network IO to occur by setting an att=
ribute. I know this is of course *possible* but this is not =
considered to be a good practice, particularly in the age of asyncio (wh=
ich I know, DBAPI is not asyncio, but these things still have interactio=
ns in practice).<br></div><div><br></div><div>The precedent however is t=
hat DBAPIs take lots of liberties with things whether the DBAPI spec all=
ows them to or not. <br></div><div><br></div></body></=
html>
--50dc3cb7d1614c15bcc29998cedf84c1--
--===============4190027365797030491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
DB-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/db-sig
--===============4190027365797030491==--