Allow generated SQL to specify their own transaction requirements.

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

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.

Summary ID
Allow generated SQL to specify their own transaction requirements.
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.
cbe21bcb47ddd1e2a7a37adc8861bf3a889d1772
Description From Last Updated

F401 'django_evolution.utils.sql.SQLExecutor' imported but unused

reviewbotreviewbot

Typo: outisde

daviddavid
Checks run (1 failed, 1 succeeded)
flake8 failed.
JSHint passed.

flake8

chipx86
david
  1. 
      
  2. django_evolution/db/sqlite3.py (Diff revision 2)
     
     
    Show all issues

    Typo: outisde

  3. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to master (7849626)
Loading...