Boxfuse 
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 hooks Flyway supports:
| Name | Execution |
|---|---|
| beforeMigrate | Before Migrate runs |
| beforeEachMigrate | Before every single migration during Migrate |
| afterEachMigrate | After every single migration during Migrate |
| afterMigrate | After Migrate runs |
| beforeClean | Before Clean runs |
| afterClean | After Clean runs |
| beforeInfo | Before Info runs |
| afterInfo | After Info runs |
| beforeValidate | Before Validate runs |
| afterValidate | After Validate runs |
| beforeBaseline | Before Baseline runs |
| afterBaseline | After Baseline runs |
| beforeRepair | Before Repair runs |
| afterRepair | After Repair runs |
Callbacks can be implemented either in SQL or in Java.
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 callback 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.
Note: Flyway will also honor any sqlMigrationSuffix you have configured, when scanning for SQL call callbacks.
If SQL Callbacks aren't flexible enough for you, you have the option to implement the FlywayCallback interface yourself. You can even hook multiple Callback implementations in the lifecycle.
More info: Java-based Callbacks