Message410305
On 08.01.2022 21:56, Erlend E. Aasland wrote:
>
> Marc-André: since Python 3.6, the sqlite3.Cursor.lastrowid attribute does no longer comply with the recommendations of PEP 249:
>
> Previously, lastrowid was set to None for operations other than INSERT or REPLACE. This changed with ab994ed8b97e1b0dac151ec827c857f5e7277565 (in Python 3.6), so that lastrowid is _unchanged_ for operations other than INSERT or REPLACE, and it is set to 0 after the first valid SQL (that is not INSERT/REPLACE) is executed on the cursor.
>
> Now, PEP 249 only _recommends_ that lastrowid is set to None for operations that do not modify a row, so it's probably not a big deal. No-one has ever mentioned this change in behaviour; there have been no bug reports.
>
> FTR, here is the relevant quote from PEP 249:
>
> If the operation does not set a rowid or if the database does not support
> rowids, this attribute should be set to None.
>
> (I interpret "should" as understood by RFC 2119.)
Well, it may be a little stronger than the SHOULD in the RFC, but then
again the whole DB-API is about conventions and if they don't make sense
for a database backend, it is possible to deviate from the spec, esp. for
optional extensions such as .lastrowid.
> So, my follow-up question becomes:
> I see no point in reverting to pre Python 3.6 behaviour. I would rather change the default value to be 0 (to get rid of the dirty flag in GH-30380), and to make the behaviour more consistent with how the actual SQLite API behaves.
>
>
> Do you have an opinion about such a change (in behaviour)?
Is 0 a valid row ID in SQLite ? If not, then I guess this would be
an alternative to None as suggested by the DB-API.
If it is a valid row ID, I'd suggest to go back to resetting to None,
since otherwise code might get confused: if an UPDATE does not get
applied (e.g. a condition is false), code could then still take
.lastrowid as referring to the UPDATE and not a previous
operation, since code will now know whether the condition was met
or not.
--
Marc-Andre Lemburg
eGenix.com |
|
Date |
User |
Action |
Args |
2022-01-11 15:04:07 | lemburg | set | recipients:
+ lemburg, erlendaasland, felixxm |
2022-01-11 15:04:07 | lemburg | link | issue46249 messages |
2022-01-11 15:04:06 | lemburg | create | |
|