Plugin Version
N/A (internal maintenance task, not version-specific)
Proposed functionality
PR #591 adds new M2M through tables with a deferrable FK constraint on target_id so that branch merges can insert rows before the referenced target custom object exists (the FK check is deferred to commit time).
However, the deferrable FK is only added when the through table is newly created. Installations that already have a through table with the previous immediate (non-deferrable) FK constraint are not upgraded by that PR.
Add an idempotent repair path — likely in create_m2m_table() or a one-time migration helper — that:
- Detects whether an existing through table's
target_id FK constraint is deferrable.
- If not, drops the old constraint and adds the deferrable replacement.
The repair must be safe to run on installations that have already been updated (idempotent), and must handle the case where no FK constraint exists at all (e.g. tables created with db_constraint=False).
Use case
Existing installations with direct M2M fields created before PR #591 will have non-deferrable FK constraints on their through tables. Without this repair, branch merges for those fields will continue to fail with FK violation errors, even after upgrading to a release that includes #591. This follow-up ensures the fix is complete for all installations, not just new ones.
External dependencies
None
Plugin Version
N/A (internal maintenance task, not version-specific)
Proposed functionality
PR #591 adds new M2M through tables with a deferrable FK constraint on
target_idso that branch merges can insert rows before the referenced target custom object exists (the FK check is deferred to commit time).However, the deferrable FK is only added when the through table is newly created. Installations that already have a through table with the previous immediate (non-deferrable) FK constraint are not upgraded by that PR.
Add an idempotent repair path — likely in
create_m2m_table()or a one-time migration helper — that:target_idFK constraint is deferrable.The repair must be safe to run on installations that have already been updated (idempotent), and must handle the case where no FK constraint exists at all (e.g. tables created with
db_constraint=False).Use case
Existing installations with direct M2M fields created before PR #591 will have non-deferrable FK constraints on their through tables. Without this repair, branch merges for those fields will continue to fail with FK violation errors, even after upgrading to a release that includes #591. This follow-up ensures the fix is complete for all installations, not just new ones.
External dependencies
None