Repository navigation
Conversation
| ' ("{forward_field}") ON DELETE CASCADE\n' | ||
| "){extra}{comment};" | ||
| ) | ||
| M2M_TABLE_NO_CONSTRAINT_TEMPLATE = ( |
There was a problem hiding this comment.
Does this template work with MySQL?
There was a problem hiding this comment.
No, it didn't. Sorry for the slow answer. MySQL, MSSQL and Oracle build the through table from their own M2M_TABLE_TEMPLATE, so the base template never reached them and they still emitted both foreign keys. The FK column path was fine, since all of them go through the base _get_fk_field_definition.
5cdedc6 adds a no-constraint template to each of the three. I also added a db_constraint=False scenario to test_schema_editor_backend_parity.py, which compares every editor's SQL with the runtime schema generator: on develop it fails for all five backends, with only the first commit it fails for MySQL, MSSQL and Oracle, and now it passes for all. Rebased onto develop as well.
53d9596 to
5cdedc6
Compare
The migration schema editor always emitted the FOREIGN KEY reference for ForeignKeyField/ManyToManyField regardless of db_constraint, unlike the runtime schema generator. Guard FK emission in _get_fk_field_definition on fk_field.db_constraint, and add a no-constraint M2M through-table template, mirroring schema_generator. The plain column (and through table) are still emitted; only the FK constraint is dropped when db_constraint=False.
These editors build the through table from their own template, so the base change did not reach them. Add a db_constraint=False scenario to the backend parity test, which compares each editor with the runtime schema generator.
5cdedc6 to
faebf04
Compare
This branch has not been deployed
2 participants
Description
The migration schema editor always emitted the
FOREIGN KEYreference forForeignKeyField/ManyToManyField, ignoringdb_constraint=False— unlike the runtime schema generator, which respects it.grep db_constraint tortoise/migrations/returned zero matches, confirming the migration subsystem ignored the flag.Motivation and Context
Closes #2223. Models that set
db_constraint=False(to avoid a hard DB-level FK while keeping the ORM relation) still got a constrained FK in generated migrations, defeating the flag.How Has This Been Tested?
_get_fk_field_definition: guard the_get_fk_reference_string(...)append onfk_field.db_constraint(mirrorsbackends/base/schema_generator.py:264). Coverscreate_modelandadd_field._get_m2m_table_definition: a no-constraint through-table template selected whennot field.db_constraint(mirrorsschema_generator.py:328/370); the unique index is still emitted.tests/migrations/test_schema_editor_sql.py(FK increate_model, FK viaadd_field, M2M) assert noREFERENCES/FOREIGN KEYwhile the column remains — red→green. Full sqlite suite: 1912 passed, 0 failures.Checklist
CHANGELOG.rstupdatedruff check/ruff format --checkclean