Hi @pverley,
Based on the error and the columns that are included in your spmerging table, it looks like an older version of the record merging migrations was run on your database before the final release.
For reference, this is what the table should look like:
Is it possible you were or are using the edge Docker tag for your deployment of Specify 7? If so, you may have pulled our work-in-progress changes on the production branch on GitHub.
This migration issue was likely introduced sometime before the release of Specify 7.9.0 as we solidified which fields were included when that arrived.
As @markp mentioned, we were used the edge Docker tag on our demo instance during that time period which means it is also affected by this issue.
Make sure to backup your database before performing any changes via SQL!
To resolve this on my end for the demo instance, I had to drop the tables that were introduced after the merging (7.9.0) update (including spmerging, uniquenessrule, and uniquenessrule_fields.
Note that I would back these tables up individually before dropping them if they contained data. Because they were empty, I was able to remove them without any issue.
drop table sp7demofish.spmerging;
drop table sp7demofish.uniquenessrule;
drop table sp7demofish.uniquenessrule_fields;
Once I did this, the migrations ran successfully after I ran docker compose up. See the logs from the back-end container (specifycloud-sp7demofish-1) in Docker:
specifycloud-sp7demofish-1 | Updating static files in /volumes/static-files/.
specifycloud-sp7demofish-1 | Applying Django migrations.
specifycloud-sp7demofish-1 | Operations to perform:
specifycloud-sp7demofish-1 | Apply all migrations: accounts, attachment_gw, auth, businessrules, contenttypes, notifications, permissions, sessions, workbench
specifycloud-sp7demofish-1 | Running migrations:
specifycloud-sp7demofish-1 | Applying businessrules.0001_initial... OK
specifycloud-sp7demofish-1 | Applying businessrules.0002_default_unique_rules... OK
specifycloud-sp7demofish-1 | Applying notifications.0003_spmerging... OK
specifycloud-sp7demofish-1 | Applying notifications.0004_rename_merge_policy... OK
specifycloud-sp7demofish-1 | Applying notifications.0005_auto_20240530_1512... OK
specifycloud-sp7demofish-1 | Applying notifications.0006_localityupdate_localityupdaterowresult... OK
specifycloud-sp7demofish-1 | Applying permissions.0006_add_dataset_create_recordset_permission... OK
specifycloud-sp7demofish-1 | Applying permissions.0007_add_stats_edit_permission... OK
specifycloud-sp7demofish-1 | Applying permissions.0008_attachment_import_role... OK
specifycloud-sp7demofish-1 | [2024-08-02 16:12:51 +0000] [8] [INFO] Starting gunicorn 22.0.0
specifycloud-sp7demofish-1 | [2024-08-02 16:12:51 +0000] [8] [INFO] Listening at: http://0.0.0.0:8000 (8)
specifycloud-sp7demofish-1 | [2024-08-02 16:12:51 +0000] [8] [INFO] Using worker: gthread
specifycloud-sp7demofish-1 | [2024-08-02 16:12:52 +0000] [16] [INFO] Booting worker with pid: 16
The migrations were then re-run properly, ensuring the tables were created correctly. Now, the https://sp7demofish.specifycloud.org/ instance can merge records as expected, and I have updated the backup used for restoring the instance to prevent this issue from occurring again.
@pverley What steps you need to take to resolve this issue depend on the status of your current migrations. Can you either send us a backup of your database or send us the contents of the django_migrations table?
Thank you!