• 
      

    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:
    Completed
    Change Summary:
    Pushed to master (7849626)