This order of operations is more in line with SQLite's documented table
rebuild procedure and ensures that changes aren't committed if foreign key
integrity is broken.
SQLite 3.26 changed the behavior of table and column renaming operations to
repoint foreign key references even if foreign key checks are disabled.
This makes the workarounds in place to simulate this behavior unnecessary on
SQLite 3.26+. Refs #30033.
Refs #29182.
The previous implementation was following a procedure explicitly documented
as incorrect and was the origin of the breakage experienced on SQLite 3.26
release that were addressed by c8ffdbe514.
Thanks to Richard Hipp for pointing out the usage of the incorrect procedure.
Prior to this change foreign key constraint references could be left pointing
at tables dropped during operations simulating unsupported table alterations
because of an unexpected failure to disable foreign key constraint checks.
SQLite3 does not allow disabling such checks while in a transaction so they
must be disabled beforehand.
Thanks ezaquarii for the report and Carlton and Tim for the review.
SQLite 3.26 repoints foreign key constraints on table renames even when
foreign_keys pragma is off which breaks every operation that requires
a table rebuild to simulate unsupported ALTER TABLE statements.
The newly introduced legacy_alter_table pragma disables this behavior
and restores the previous schema editor assumptions.
Thanks Florian Apolloner, Christoph Trassl, Chris Lamb for the report and
troubleshooting assistance.
Removed DatabaseIntrospection.table_name_converter()/column_name_converter()
and use instead DatabaseIntrospection.identifier_converter().
Removed DatabaseFeatures.uppercases_column_names.
Thanks Tim Graham for the initial patch and review and Simon Charette
for the review.
Added a test for constraint names in the database.
Updated SQLite introspection to use sqlparse to allow reading the
constraint name for table check and unique constraints.
Co-authored-by: Ian Foote <python@ian.feete.org>
Checked the following locations:
* Model.save(): If there are parents involved, take the safe way and use
transactions since this should be an all or nothing operation.
If the model has no parents:
* Signals are executed before and after the previous existing
transaction -- they were never been part of the transaction.
* if `force_insert` is set then only one query is executed -> atomic
by definition and no transaction needed.
* same applies to `force_update`.
* If a primary key is set and no `force_*` is set Django will try an
UPDATE and if that returns zero rows it tries an INSERT. The first
case is completly save (single query). In the second case a
transaction should not produce different results since the update
query is basically a no-op then (might miss something though).
* QuerySet.update(): no signals issued, single query -> no transaction
needed.
* Model/Collector.delete(): This one is fun due to the fact that is
does many things at once.
Most importantly though: It does send signals as part of the
transaction, so for maximum backwards compatibility we need to be
conservative.
To ensure maximum compatibility the transaction here is removed only
if the following holds true:
* A single instance is being deleted.
* There are no signal handlers attached to that instance.
* There are no deletions/updates to cascade.
* There are no parents which also need deletion.
Simon Charette
Nick Pope
Simon Charette
Tim Graham
Mariusz Felisiak
Sergey Fedoseev
Srinivas Reddy Thatiparthy
Tom Forbes
Jayantha Gumballi
Mads Jensen
thomazzo
Hampus Dunström
Florian Apolloner