Incorrect Migration Order when renaming triggers and model

[dominikbak]

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:

migrations.RenameModel(
    old_name="PartnerToBuyerDSPIntegration",
    new_name="SupplyToDemandAdPlatformIntegration",
),
pgtrigger.migrations.RemoveTrigger(
    model_name="supplytodemandadplatformintegration",
    name="unique_integration_type_for_partner_buyer",
),
pgtrigger.migrations.RemoveTrigger(
    model_name="supplytodemandadplatformintegration",
    name="check_account_partner_to_buyer_dsp_integration",
),
pgtrigger.migrations.AddTrigger(
    model_name="supplytodemandadplatformintegration",
    trigger=pgtrigger.compiler.Trigger(
        name="unique_integration_type_for_partner_buyer",
        # Trigger SQL here...
    ),
),
pgtrigger.migrations.AddTrigger(
    model_name="supplytodemandadplatformintegration",
    trigger=pgtrigger.compiler.Trigger(
        name="check_account_partner_to_buyer_dsp_integration",
        # Trigger SQL here...
    ),
),

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:

pgtrigger.migrations.RemoveTrigger(
    model_name="partnertobuyerdspintegration",
    name="unique_integration_type_for_partner_buyer",
),
pgtrigger.migrations.RemoveTrigger(
    model_name="partnertobuyerdspintegration",
    name="check_account_partner_to_buyer_dsp_integration",
),
migrations.RenameModel(
    old_name="PartnerToBuyerDSPIntegration",
    new_name="SupplyToDemandAdPlatformIntegration",
),
pgtrigger.migrations.AddTrigger(
    model_name="supplytodemandadplatformintegration",
    trigger=pgtrigger.compiler.Trigger(
        name="unique_integration_type_for_partner_buyer",
        # Trigger SQL here...
    ),
),
pgtrigger.migrations.AddTrigger(
    model_name="supplytodemandadplatformintegration",
    trigger=pgtrigger.compiler.Trigger(
        name="check_account_partner_to_buyer_dsp_integration",
        # Trigger SQL here...
    ),
),

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.

[wesleykendall]

Thanks for reporting this and for showing how people can fix it if they run into it. Will leave it open for now until there is a fix