You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when trigger is renamed, it is removed and added with the new name.
When running python manage.py makemigrations, the generated migration order is incorrect when renaming models that have associated triggers. This causes issues. Specifically, after a model rename, triggers still reference the old model name in the trigger.uninstall_sql, resulting in the trigger not being removed from the database and causing errors when the trigger is subsequently triggered.
Here is the current problematic migration order generated by Django's makemigrations:
Problem
In the pgtrigger.migrations.RemoveTrigger migration step, the function trigger.uninstall_sql still references the old model name PartnerToBuyerDSPIntegration. Since the model has already been renamed to SupplyToDemandAdPlatformIntegration, the trigger cannot be properly removed, resulting in migration errors when the trigger tries to act on the non-existent table.
Working Migration Order
The issue can be resolved by adjusting the migration order to remove triggers before renaming the model, as shown below:
Proposed Solution
To fix this issue, the pgtrigger library should either adjust the migration order or alternatively, uninstall_sql could respect the model rename, referencing the new table name in the SQL uninstall step.
The text was updated successfully, but these errors were encountered:
Currently when trigger is renamed, it is removed and added with the new name.
When running
python manage.py makemigrations
, the generated migration order is incorrect when renaming models that have associated triggers. This causes issues. Specifically, after a model rename, triggers still reference the old model name in thetrigger.uninstall_sql
, resulting in the trigger not being removed from the database and causing errors when the trigger is subsequently triggered.Here is the current problematic migration order generated by Django's makemigrations:
Problem
In the
pgtrigger.migrations.RemoveTrigger
migration step, the functiontrigger.uninstall_sql
still references the old model namePartnerToBuyerDSPIntegration
. Since the model has already been renamed toSupplyToDemandAdPlatformIntegration
, the trigger cannot be properly removed, resulting in migration errors when the trigger tries to act on the non-existent table.Working Migration Order
The issue can be resolved by adjusting the migration order to remove triggers before renaming the model, as shown below:
Proposed Solution
To fix this issue, the pgtrigger library should either adjust the migration order or alternatively,
uninstall_sql
could respect the model rename, referencing the new table name in the SQL uninstall step.The text was updated successfully, but these errors were encountered: