Skip to content

@dbmigrate

Permission: Owner (Limnoria capability)

Inquisitor stores a SHA-256 checksum of every migration file in the schema_version table when it applies the migration, and refuses to connect if a shipped migration file later changes. The error reads:

Checksum mismatch for migration 2_example. The migration file has been modified after being applied. ...

@dbmigrate rebaseline accepts the current file of one already-applied migration as applied without running it again. It only updates the stored checksum, so the bot can connect again.

Syntax

@dbmigrate rebaseline <version>
@dbmigrate rebaseline <version> confirm

How it works

  1. The first form is a preview. It shows the checksum stored when the migration was applied and the checksum of the current file, and writes nothing.
  2. Run the second form within 5 minutes, from the same hostmask, for the same version.
  3. Before writing, the bot checks that neither checksum has changed since the preview, and refuses if one did.
  4. It updates only that migration's stored checksum and writes a DB event to the master log naming who did it and the old and new checksums.
  5. Run @dbconnect afterwards.

Nothing is written, and the preview says so, when:

  • the stored checksum already matches the file;
  • the migration has never been applied to this database;
  • there is no migration file with that version;
  • the name recorded in the database differs from the file's name;
  • the database was created by a release before 1.2.0. Such a database cannot be rebaselined; see Databases from before 1.2.0.

Example

The migration name and checksums below are illustrative.

<owner> @dbmigrate rebaseline 2
<bot> Migration 2_example checksum mismatch.
<bot> Stored when applied: 4f1c0d6e9b2a7c3f8e5d1a0b6c9f2e7d3a8b5c1f0e6d9a2b7c4f8e3d1a5b0c6f
<bot> Current file: 9e2b7d4a1c8f3e6b0d5a9c2f7e4b1d8a3c6f0e9b5d2a7c4e1f8b3d6a0c9e5f2b
<bot> Rebaselining records the current file as applied WITHOUT running it again. Only confirm if the database schema already matches this file.
<bot> To confirm within 5 minutes: 'dbmigrate rebaseline 2 confirm'
<owner> @dbmigrate rebaseline 2 confirm
<bot> Migration 2_example rebaselined: 4f1c0d6e9b2a7c3f8e5d1a0b6c9f2e7d3a8b5c1f0e6d9a2b7c4f8e3d1a5b0c6f -> 9e2b7d4a1c8f3e6b0d5a9c2f7e4b1d8a3c6f0e9b5d2a7c4e1f8b3d6a0c9e5f2b. Run 'dbconnect' to connect.
<owner> @dbconnect
<bot> Database connected successfully! Run 'setup' to complete initialization.

Warning

The migration is not re-run. Rebaseline only when the file change did not change the schema the migration produces. If the schema should differ, the fix is a new migration, not a rebaseline. Every rebaseline is recorded in the master log. See Checksum Mismatch Recovery for the full procedure.