Thanks Adam Johnson and Paolo Melchiorre for reviews.
Co-Authored-By: Lily Foote <code@lilyf.org>
Co-Authored-By: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Special thanks to Hannes Ljungberg for finding multiple implementation
gaps.
Thanks also to Simon Charette, Adam Johnson, and Mariusz Felisiak for
reviews.
Black 23.1.0 is released which, as the first release of the year,
introduces the 2023 stable style. This incorporates most of last year's
preview style.
https://github.com/psf/black/releases/tag/23.1.0
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 c8ffdbe514b55ff5c9a2b8cb8bbdf2d3978c188f.
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.
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>
Introspected database constraints instead of relying on _meta.related_objects
to determine whether or not a table or a column is referenced on rename
operations.
This has the side effect of ignoring both db_constraint=False and virtual
fields such as GenericRelation which aren't backend by database level
constraints and thus shouldn't prevent the rename operations from being
performed in a transaction.
Regression in 095c1aaa898bed40568009db836aa8434f1b983d.
Thanks Tim for the additional tests and edits, and Mariusz for the review.