Allow generated SQL to specify their own transaction requirements.

Review Request #11244 — Created Oct. 25, 2020 and submitted — Latest diff uploaded

Information

Django Evolution
master

Reviewers

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, and NoTransactionSQL.
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 s VACUUM 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.

Commits

Files

    Loading...