SQLite schema editor can cause table corruption if used within a transaction since Django 2.0

[Simon Charette]

From Django 2.0+ SQLite schema editor requires foreign key constraint checking to be disabled to make sure foreign keys are not left pointing at __old tables when performing operations requiring table rebuilds.

Since ​SQLite prevents foreign key constraint checking from being disabled within a transaction SchemaEditor(atomic=True).__enter__() has no choice but to disable foreign key constraints before opening the transaction meant to ensure atomic DDL operations.

One edge case that SchemaEditor doesn't account for though is that the it might contextually be used within an already opened transaction that would prevent foreign key constraints from being effectively disabled and result in silent referent table corruption when an operation requiring a table is rebuild id performed.

In order to prevent this from happening SchemaEditor().__enter__() should ensure foreign key constraint checks are effectively disabled after requesting it and error out if it's not the case.

This assertion should be more adequate than preventing schema editor from being used in a transaction altogether as disabling constraint checks before opening a transaction works just fine as well.

For example

with transaction.atomic():
    call_command('migrate')

Just has to be converted to

with connection.constraint_checks_disabled(), transaction.atomic():
    call_command('migrate')

And work just fine.

This is was originally reported in #29182 but was hijacked to deal with a SQLite 3.26 issue with similar symptoms and can be reproduced in a ​test project.