Making dbm-rollback safe after destructive schema changes in the Grails database-migration plugin

Answer the Questions First

1. Is expand‑and‑contract the only safe pattern for destructive changes?
   No, Liquibase can make a drop‑table or drop‑column changeSet revertible by adding an explicit <rollback> block that recreates the object. However, the block only restores the schema – the data that was stored in the dropped column or table is lost unless you have an external backup. Because of that, the industry‑standard “expand‑and‑contract” pattern (add a new table/column, move data, drop the old object in a later release) is still the safest way to guarantee a full rollback.
2. Should dbCreate be set to none/validate in every environment after adopting migrations?
   Yes. Leaving dbCreate=update lets Hibernate touch the schema outside Liquibase’s control, which can reorder columns, add missing constraints, or even drop objects that Liquibase expects to exist. During a rollback, such changes can cause Liquibase to fail because the DATABASECHANGELOG table no longer matches the actual schema. Switching to none (or validate if you want Hibernate to throw on mismatches) guarantees that only Liquibase moves the schema.
3. Do teams rely on snapshots instead of dbm‑rollback for dropped data?
   Yes. When a rollback must recover data that was dropped by a dropTable or dropColumn, the typical workflow is:
   • Restore the database from a recent snapshot or backup that contains the missing data.
   • Re‑apply the Liquibase changesets that were executed after the snapshot, or truncate the DATABASECHANGELOG table and re‑run the migrations to bring the checksum state back into sync.
   This keeps the DATABASECHANGELOG table accurate while restoring the lost rows.

Practical Steps for Your Grails 5/6 Project

1. Add <rollback> Blocks for Destructive ChangeSets

<changeSet id="2026-10-13-drop-user-email" author="me">
  <dropColumn tableName="user" columnName="email" />
  <rollback>
    <addColumn tableName="user">
      <column name="email" type="varchar(255)"/>
    </addColumn>
  </rollback>
</changeSet>

Note: The rollback block restores the column definition but not the data that was stored in it. If you need the data back, you’ll still need a snapshot.

2. Switch dbCreate to none (or validate)

grails:
  datasource:
    default:
      dbCreate: none
      url: jdbc:postgresql://localhost:5432/mydb
      username: app
      password: secret

After changing this, run a full migration in a staging environment to confirm that no Hibernate‑generated DDL appears.

3. Verify Rollback Works in Staging

1. Run grails dbm-update to apply the latest changes.
2. Run grails dbm-rollback -Dtarget=2026-10-13-drop-user-email to test the rollback of the specific changeSet.
3. Check DATABASECHANGELOG to ensure the checksum matches the rolled‑back file.

4. Handling Dropped Data During Production Rollback

• Take a database snapshot before the rollout (e.g., pg_dump -Fc for PostgreSQL).
• If a rollback is needed, restore the snapshot: pg_restore -d mydb snapshot.dump.
• Re‑apply any migrations that were executed after the snapshot to bring the DATABASECHANGELOG table up to date. If you want to keep the checksums, you can truncate the table and run grails dbm-update again.

5. Automate the Process with a Script

#!/usr/bin/env bash
set -e
# 1. Take snapshot
pg_dump -Fc -f /backups/$(date +%F).dump mydb
# 2. Apply migrations
grails dbm-update
# 3. If rollback needed
# grails dbm-rollback -Dtarget=TARGET_CHANGESET
# 4. Restore snapshot
# pg_restore -d mydb /backups/$(date +%F).dump

What to Verify After Each Change

• Run grails dbm-validate to ensure the checksums match.
• Check DATABASECHANGELOG for any FAILED entries.
• In production, monitor for Hibernate warnings about schema mismatches.

Missing Diagnostic Detail

To tailor the rollback script for your environment, could you confirm which database engine you’re using (PostgreSQL, MySQL, Oracle, etc.) and whether you have a scheduled snapshot strategy already in place?