Callbacks

While migrations are sufficient for most needs, there are certain situations that require you to execute the same action over and over again. This could be recompiling procedures, updating materialized views and many other types of housekeeping.

For this reason, MigrateDB offers you the possibility to hook into its lifecycle by using Callbacks.

These are the events MigrateDB supports:

Name	Execution
beforeMigrate	Before Migrate runs
beforeRepeatables	Before all repeatable migrations during Migrate
beforeEachMigrate	Before every single migration during Migrate
beforeEachMigrateStatement	Before every single statement of a migration during Migrate
afterEachMigrateStatement	After every single successful statement of a migration during Migrate
afterEachMigrateStatementError	After every single failed statement of a migration during Migrate
afterEachMigrate	After every single successful migration during Migrate
afterEachMigrateError	After every single failed migration during Migrate
afterMigrate	After successful Migrate runs
afterMigrateApplied	After successful Migrate runs where at least one migration has been applied
afterVersioned	After all versioned migrations during Migrate
afterMigrateError	After failed Migrate runs


beforeClean	Before Clean runs
afterClean	After successful Clean runs
afterCleanError	After failed Clean runs

beforeInfo	Before Info runs
afterInfo	After successful Info runs
afterInfoError	After failed Info runs

beforeValidate	Before Validate runs
afterValidate	After successful Validate runs
afterValidateError	After failed Validate runs

beforeBaseline	Before Baseline runs
afterBaseline	After successful Baseline runs
afterBaselineError	After failed Baseline runs

beforeRepair	Before Repair runs
afterRepair	After successful Repair runs
afterRepairError	After failed Repair runs

createSchema	Before automatically creating non-existent schemas
beforeConnect	Before MigrateDB connects to the database

Callbacks can be implemented either in SQL or in Java.

SQL Callbacks

The most convenient way to hook into MigrateDB’s lifecycle is through SQL callbacks. These are simply sql files in the configured locations following a certain naming convention: the event name followed by the SQL migration suffix.

Using the default settings, MigrateDB looks in its default locations (<install_dir>/sql) for the Command-line tool) for SQL files like beforeMigrate.sql, beforeEachMigrate.sql, afterEachMigrate.sql, …

Placeholder replacement works just like it does for SQL migrations.

Optionally the callback may also include a description. In that case the callback name is composed of the event name, the separator, the description and the suffix. Example: beforeRepair__vacuum.sql.

Note: MigrateDB will also honor any sqlMigrationSuffixes you have configured, when scanning for SQL callbacks.

Java Callbacks

If SQL Callbacks aren’t flexible enough for you, you have the option to implement the Callback interface yourself. You can even hook multiple Callback implementations in the lifecycle. Java callbacks have the additional flexibility that a single Callback implementation can handle multiple lifecycle events, and are therefore not bound by the SQL callback naming convention.

More info: Java-based Callbacks

Script Callbacks

Much like SQL callbacks, MigrateDB also supports the execution of callbacks written in a scripting language. The supported file extensions are the same as those supported by script migrations. For example, you could have a beforeRepair__vacuum.ps1 callback. Script callbacks give you much more flexibility and power during the migration lifecycle. Some of the things you can achieve are:

Executing external tools between migrations
Creating or cleaning local files for migrations to use

Callback ordering

When multiple callbacks for the same event are found, they are executed in the alphabetical order.

Tutorial

Click here to see a tutorial on using callbacks.

Error Overrides ➡️