Want to deploy your JVM, Node.js and Go apps effortlessly to AWS? Try our service Boxfuse

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, Flyway offers you the possibility to hook into its lifecycle by using Callbacks.

These are the events Flyway supports:

Name Execution
beforeMigrate Before Migrate runs
beforeEachMigrate Before every single migration during Migrate
beforeEachMigrateStatement Flyway Pro Before every single statement of a migration during Migrate
afterEachMigrateStatement Flyway Pro After every single successful statement of a migration during Migrate
afterEachMigrateStatementError Flyway Pro 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
afterMigrateError After failed Migrate runs
beforeUndo Flyway Pro Before Undo runs
beforeEachUndo Flyway Pro Before every single migration during Undo
beforeEachUndoStatement Flyway Pro Before every single statement of a migration during Undo
afterEachUndoStatement Flyway Pro After every single successful statement of a migration during Undo
afterEachUndoStatementError Flyway Pro After every single failed statement of a migration during Undo
afterEachUndo Flyway Pro After every single successful migration during Undo
afterEachUndoError Flyway Pro After every single failed migration during Undo
afterUndo Flyway Pro After successful Undo runs
afterUndoError Flyway Pro After failed Undo 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

Callbacks can be implemented either in SQL or in Java.

SQL Callbacks

The most convenient way to hook into Flyway’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, Flyway 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.

When multiple SQL callbacks for the same event are found, they are executed in the order of their description.

Note: Flyway 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.

More info: Java-based Callbacks

Error Overrides