Trax .NET
View as MarkdownEdit on GitHub

How-to guide

Repair a partial migration 014

Source 014_manifest_group.sql

014_manifest_group.sql cannot run twice. If it stopped partway (a killed process, a failed statement), the next start runs it again from the top and fails on CREATE TABLE trax.manifest_group, because the table is already there. What it does is described in Schema migrations.

Stop every host on the database before you start, and take a backup.

1. Confirm 014 is not recorded

SELECT scriptname, applied FROM trax.migrations ORDER BY applied DESC LIMIT 5;

If a row ends in 014_manifest_group.sql, the migration completed and this guide does not apply: the failure is elsewhere.

2. Find how far it got

SELECT column_name FROM information_schema.columns
WHERE table_schema = 'trax' AND table_name = 'manifest'
  AND column_name IN ('group_id', 'manifest_group_id');
ResultThe script
group_id onlystopped after creating trax.manifest_group, or while seeding it
bothstopped while filling or constraining manifest_group_id, or before dropping group_id
manifest_group_id onlyran every statement; only the journal row is missing

3a. While group_id still exists: undo it

Remove what the script created, then start a host. 014 runs again from the top, against the manifests as they were.

ALTER TABLE trax.manifest DROP CONSTRAINT IF EXISTS fk_manifest_manifest_group;
DROP INDEX IF EXISTS trax.ix_manifest_manifest_group_id;
ALTER TABLE trax.manifest DROP COLUMN IF EXISTS manifest_group_id;
DROP TABLE IF EXISTS trax.manifest_group;

3b. When group_id is gone: record it

Every statement ran, so add the journal row DbUp did not write. Copy the scriptname of the 013 row and change its file name to 014_manifest_group.sql:

INSERT INTO trax.migrations (scriptname, applied)
SELECT replace(scriptname, '013_priority.sql', '014_manifest_group.sql'), now()
FROM trax.migrations
WHERE scriptname LIKE '%013_priority.sql';

Then start a host. The migrator skips 014 and applies the scripts after it.

Related