Changes between Initial Version and Version 1 of Ticket #29182, comment 6


Ignore:
Timestamp:
03/04/2018 08:40:02 PM (2 years ago)
Author:
Simon Charette
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #29182, comment 6

    initial v1  
    33You can get a bit of context about why all the SQLite constraint workarounds are required in #28849 but in this case I suspect odd things happen because, as you might know, savepoints are used in nested `atomic()` blocks.
    44
    5 The migration executor was not designed to be used within a transaction as it does some pretty intense transaction management itself so I'm accepting on the basis that we should do a better job at raising an error in this case. The fact that this doesn't happen when `./manage.py migrate` is called directly is a good indicator that other weird things might be happening under the hood because this case is completely untested by the suite right now. For example, do the backend that we know transactional DDL support for all behave the same way with regards to savepoints?
     5The migration executor was not designed to be used within a transaction as it does some pretty intense transaction management itself so I'm accepting on the basis that we should do a better job at raising an error in this case. The fact that this doesn't happen when `./manage.py migrate` is called directly is a good indicator that other weird things might be happening under the hood because this case is completely untested by the suite right now. For example, do the backends that we assume have transactional DDL support all behave the same way with regards to DDL in savepoints?
    66
    77I guess you were trying to come up with some kind of deploying script that either fails or succeeds to apply multiple migrations?
     8
     9I think the best place to raise the error from would be in `sqlite3.DatebaseSchemaEditor.__enter__` when `disable_constraint_checking` returns `False` to signify the operation didn't succeed as database alteration methods the returned instance exposes all assume foreign key constraints are disabled. FWIW the reason why `disable_constraint_checking` returns false within a transaction is that `PRAGMA foreign_keys = ON/OFF` has absolutely no effect in a transaction which is one of the reason why the workarounds in #28849 had to be implemented.
Back to Top