4 ms·
Performing a separate request for the last-inserted row has always struck me as a literally insane idea. Of course it's incredibly error prone! How could it be
by Groxx 4y ago
Performing a separate request for the last-inserted row has always struck me as a literally insane idea. Of course it's incredibly error prone! How could it be anything else?
How the heck did it come into existence?
- cryptonector 4y agoYes, that was always kinda nonsense. You really need RETURNING.
- masklinn 4y ago> How the heck did it come into existence? Probably implementation simplicity: sqlite_last_insert_rowid() dates back to the "dark ages" of mysql (it was added in 2.2.3, released 2002-01-16). The alternative is to add RETURNING, which for that sole purpose is rather complicated. sqlite only added RETURNING in 3.35.0 (2021-03-12), and that was also motivated by the addition of upserts (ON CONFLICT clauses), for which last_insert_rowid really doesn't work. Furthermore, sqlite really only added multithreading support reluctantly, per its FAQ: > (6) Is SQLite threadsafe? > Threads are evil. Avoid them. Multithreading support was added in 2.2.3 (2002-01-16), but it wasn't even possible to move connections between threads until 3.3.3 (2006-01-31), and using the same connection from multiple threads concurrently was not supported until 3.5.1 (2007-10-04).