This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author erlendaasland
Recipients erlendaasland, lemburg
Date 2022-01-04.20:02:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1641326546.98.0.599089795621.issue46249@roundup.psfhosted.org>
In-reply-to
Content
> If possible, it's usually better to have the .executemany() create a
> cursor with an output array providing the row ids, e.g. using "INSERT ...
> RETURNING ..." (PostgreSQL). That way you can access all row ids and
> can also provide the needed detail in case the INSERTs happen out of
> order to map them to the input data.

Hm, maybe so. But it will add a lot of overhead and complexity to executemany(), and there haven't been requests for this feature for sqlite3. AFAIK, there hasn't been request for lastrowid for executemany() at all. OTOH, my proposal of modifying lastrowid to always show the rowid of the actual last inserted row is a very cheap operation, _and_ it simplifies the code (=> increased maintainability), so I think I'll go for that.

> For cases where you don't need sequence IDs, it's often better to
> not rely on auto-increment columns for IDs, but instead use random
> pre-generated IDs. Saves roundtrips to the database and works nicely
> with cluster databases as well.

Yes, but in those cases you keep track of the row id yourself, so you probably won't need lastrowid ;)
History
Date User Action Args
2022-01-04 20:02:27erlendaaslandsetrecipients: + erlendaasland, lemburg
2022-01-04 20:02:26erlendaaslandsetmessageid: <1641326546.98.0.599089795621.issue46249@roundup.psfhosted.org>
2022-01-04 20:02:26erlendaaslandlinkissue46249 messages
2022-01-04 20:02:26erlendaaslandcreate