Yes, I know that this is off-topic, but I feel justified by sqlite3
being a builtin.
The default ON CONFLICT algorithm in SQLite is ABORT.
The SQLite documentation ("ON CONFLICT clause") says that when
a constraint violation occurs under ABORT, no rollback is executed,
so changes from prior commands within the same transaction are
preserved.
Isn't this a strange choice for a default ?
After all, you expect that either all changes within a transaction
are preserved, or that nothing at all is preserved.
The Python Library Reference on sqlite3 says in paragraph 13.13.5
that I should not use the ROLLBACK conflict algorithm in my sql.
Instead I have to catch the IntegrityError and call the rollback method.
Does that mean that I have to wrap all multi-command transactions
in a try-except if I don't like the default ABORT choice ?
e
--
Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991
=============== =============== =============== =============== ============
being a builtin.
The default ON CONFLICT algorithm in SQLite is ABORT.
The SQLite documentation ("ON CONFLICT clause") says that when
a constraint violation occurs under ABORT, no rollback is executed,
so changes from prior commands within the same transaction are
preserved.
Isn't this a strange choice for a default ?
After all, you expect that either all changes within a transaction
are preserved, or that nothing at all is preserved.
The Python Library Reference on sqlite3 says in paragraph 13.13.5
that I should not use the ROLLBACK conflict algorithm in my sql.
Instead I have to catch the IntegrityError and call the rollback method.
Does that mean that I have to wrap all multi-command transactions
in a try-except if I don't like the default ABORT choice ?
e
--
Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991
=============== =============== =============== =============== ============