There are three ways you can hook into the Flyway API.
The first one is the the most common one: Java-based Migrations when you need more power than SQL can offer you. This is great to for dealing with LOBs or performing advanced data transformations.
This can be achieved by implementing the JdbcMigration interface.
Alternatively Spring users may prefer to implement the SpringJdbcMigration interface to gain access to a Spring JdbcTemplate instead of a plain JDBC connection.
For even more flexibility with regard to naming and checksums you can additionally implement the MigrationInfoProvider and MigrationChecksumProvider interfaces.
To access the Flyway configuration your migration can implement ConfigurationAware and Flyway will automatically inject an instance of FlywayConfiguration.
Building upon that are the Java-based Callbacks when you need more power or flexibility in a Callback than SQL can offer you.
This can be achieved by implementing the FlywayCallback interface.
For your convenience, you can also subclass org.flywaydb.core.api.callback.BaseFlywayCallback
which already contains no-op implementations of all the methods of the org.flywaydb.core.api.callback.FlywayCallback
interface.
To access the Flyway configuration your callback can implement ConfigurationAware and Flyway will automatically inject an instance of FlywayConfiguration.
For those that need more than what the SQL and Java-based migrations offer, you also have the possibility to implement your own MigrationResolver coupled with a custom MigrationExecutor.
These can then be used for loading things like CSV-based migrations or other custom formats.
To access the Flyway configuration your resolver can implement ConfigurationAware and Flyway will automatically inject an instance of FlywayConfiguration.
By using the skipDefaultResolvers property, these custom resolvers can also be used to completely replace the built-in ones (by default, custom resolvers will run in addition to built-in ones).