Update 2014-04-29: This is now Possible with Flyway 3.0 by implementing the FlywayCallback interface.

Previous answer

The short answer is: no, not at this point.

Here is the reason: I thought about this as well as I was laying down the initial design for Flyway. The more I thought about this aspect though, the more it became clear to me that these pre and post scripts are also an integral part of the migration, or at least something a migration can not do without if it wants to be successful. Therefore I would recommend to either:

• Merge 1, 2 & 3 in a single migration
• Have 3 separate migrations x.1 (drop views), x.2 (actual migration), x.3 (rebuild views)

You might even be able to have x.1 and x.3 call stored procedures that do the work for you to avoid code duplication between migrations if these steps are repeating.

Having Flyway take care of performing all changes to the database structure makes the whole thing more straightforward, avoiding a mix of different technologies.

To expand on Axel s response: callbacks with sql scripts simply means putting beforeMigrate.sql (for instance, this is one keyword among others) in the directory containing the migrations, and Flyway will execute beforeMigrate.sql before the other migration scripts. Even before schema_version gets locked.

Other callback names (e.g. afterMigrate) are listed in the documentation for callbacks.

you should use flyway Callbacks like:

https://flywaydb.org/documentation/concepts/callbacks#beforeEachMigrate https://flywaydb.org/documentation/concepts/callbacks#beforeEachMigrate

see also : https://flywaydb.org/documentation/tutorials/callbacks.html

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.

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. 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