Allow generated SQL to specify their own transaction requirements.
Review Request #11244 — Created Oct. 25, 2020 and submitted — Latest diff uploaded
Most of the time, generated SQL is intended to run within a transacton.
We normally don't need to worry about it. However, there are situations
in which some generated SQL must run in either a brand-new transaction,
or completely outside of a transaction.The recent introduction of
SQLExecutor
was built to lay the ground
work for this. This change follows up by introducing new wrappers for
lists of SQL statements:NewTransactionSQL
, andNoTransactionSQL
.
Any list of statements in generated SQL can be wrapped in one of these
to, respectively, execute in a brand-new transaction (committing any
previous one first) or execute outside of a transaction.The SQLite code for renaming a primary key has been updated to make use
of this. This code needed to commit a transaction, execute new code in
another transaction, and then send sVACUUM
comamnd outside of a
transaction. The method used for this was hacky and falls apart with
some in-progress work. Now, using these wrappers, it's safe,
future-proof, and compatible with other transaction work.
Unit tests passed on all versions of Python and Django.
Tested creating and updating databases.