Marc-Andre Lemburg <m...@egenix.com> added the comment:
On 04.01.2022 00:49, Erlend E. Aasland wrote: > > Erlend E. Aasland <erlend.aasl...@innova.no> added the comment: > > I see that PEP 249 does not define the semantics of lastrowid for > executemany(). What's the precedence here, MAL? IMO, it would be nice to be > able to fetch the last row id after you've done a 1000 inserts using > executemany(). The DB-API deliberately leaves this undefined, since there are many ways you could implement this, e.g. - return the last row id for the last entry in the array passed to .executemany() - return the last row id of the last actually modified/inserted row after running .executemany() - return an array of row ids, one for each row modified/inserted - return a row id of one of the modified/inserted rows, without defining which - always return None for .executemany() Note that in some cases, the order of actions taken by the database is not predefined (e.g. some databases run such inserts in chunks across a cluster), so even the "last" semantics are not clear. > So, another option would be to keep "set-lastrowid" in the query loop, and > just remove the condition; we set it every time (but of course only build a > PyObject of it when the loop is done). Since the DB-API leaves this undefined, you are free to add your own meaning, which makes most sense for SQLite, to always return None or not implement it at all. DB-API extensions such as Cursor.lastrowid are optional and don't need to be implemented if they don't make sense for a particular use case: https://www.python.org/dev/peps/pep-0249/#optional-db-api-extensions ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46249> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
