The LoadTriggers function was not properly returning all of the triggers in the database, resulting in missing triggers in the resulting Schema object and in the final results of pgmigrate dump. The root cause was that triggers may share the same name as long as they're attached to different tables, but the SortKey() implementation for a Trigger only used the trigger.Name. This led to triggers colliding during the sorting process, with just one trigger of a given name making it to the result.
The fix is to use a combination of the trigger's table and its name during the sorting process. I confirmed the problem and the fix by writing unit tests — trigger loading was previously untested.
While developing this fix, I noticed that the golangci-lint configuration was resulting in many lint errors. I updated this configuration and fixed these lint errors. The only change that affects behavior was that in the migratorops code, there were multiple cases of a transaction tx being opened but then queries would be run against the db, not the tx.
The breaking behavioral change is that in the mark-applied, mark-unapplied, and set-checksums operations, now either all of the migration records are updated or none of them are. Previously, some could succeed while others later failed.
The
LoadTriggersfunction was not properly returning all of the triggers in the database, resulting in missing triggers in the resultingSchemaobject and in the final results ofpgmigrate dump. The root cause was that triggers may share the same name as long as they're attached to different tables, but theSortKey()implementation for aTriggeronly used thetrigger.Name. This led to triggers colliding during the sorting process, with just one trigger of a given name making it to the result.The fix is to use a combination of the trigger's table and its name during the sorting process. I confirmed the problem and the fix by writing unit tests — trigger loading was previously untested.
While developing this fix, I noticed that the golangci-lint configuration was resulting in many lint errors. I updated this configuration and fixed these lint errors. The only change that affects behavior was that in the
migratoropscode, there were multiple cases of a transactiontxbeing opened but then queries would be run against thedb, not thetx.The breaking behavioral change is that in the
mark-applied,mark-unapplied, andset-checksumsoperations, now either all of the migration records are updated or none of them are. Previously, some could succeed while others later failed.