Configure resource providers
In May we received request from our friends at Quarkus asking that we allow users more control over how Flyway looks up resources. By resources, we mean things like migrations, callbacks, and so on. They were even kind enough to provide a Pull Request!
The Pull Request was merged, and the changes released in Flyway 6.5. In this blog I’ll explain a bit more about how this new feature works.
Injecting a ResourceProvider
By default, Flyway will use a process of recursive classpath scanning to find resources. Let’s look at a simple programmatic configuration of Flyway:
|
1 2 3 4 5 6 7 |
<strong>Flyway</strong> flyway = <strong>Flyway</strong>.configure() .dataSource("jdbc:h2:mem:db", "sa", "password") .locations("db/migration") .load(); flyway.migrate(); |
locations is set to a folder, db/migration. Flyway will perform a recursive scan of this folder to search for the resources it needs to perform the migration.
We’ve now expanded Flyway’s API to allow you override this behavior with custom Java code. You can specify your own override of the ResourceProvider abstract class, which defines a contract for a class that can supply resources to Flyway.
A simple implementation might look like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
<strong>LoadableResource</strong> loadableResource = <strong>new</strong> <strong>LoadableResource</strong>() { @Override <strong>public</strong> <strong>Reader</strong> read() { <strong>try</strong> { <strong>return</strong> <strong>new</strong> FileReader("C:\\V1__migration.sql"); } <strong>catch</strong> (<strong>FileNotFoundException</strong> e) { <em>// No op</em> } <strong>return</strong> <strong>null</strong>; } @Override <strong>public</strong> <strong>String</strong> getAbsolutePath() { <strong>return</strong> "C:\\V1__migration.sql"; } @Override <strong>public</strong> <strong>String</strong> getAbsolutePathOnDisk() { <strong>return</strong> "C:\\V1__migration.sql"; } @Override <strong>public</strong> <strong>String</strong> getFilename() { <strong>return</strong> "V1__migration.sql"; } @Override <strong>public</strong> <strong>String</strong> getRelativePath() { <strong>return</strong> "V1__migration.sql"; } }; <strong>Flyway</strong> flyway = <strong>Flyway</strong>.configure() .dataSource("jdbc:h2:mem:db", "sa", "password") .resourceProvider(<strong>new</strong> <strong>ResourceProvider</strong>() { @Override <strong>public</strong> <strong>LoadableResource</strong> getResource(<strong>String</strong> name) { <strong>return</strong> loadableResource; } @Override <strong>public</strong> <strong>Collection</strong><<strong>LoadableResource</strong>> getResources(<strong>String</strong> prefix, <strong>String</strong>[] suffixes) { <strong>ArrayList</strong><<strong>LoadableResource</strong>> arr = <strong>new</strong> <strong>ArrayList</strong><>(); arr.add(loadableResource); <strong>return</strong> arr; } }) .load(); flyway.migrate(); |
We’ve defined a LoadableResource object which points to a single migration V1__migration.sql. We call .resourceProvider when setting up the configuration to give Flyway a custom ResourceProvider, which in turn provides a LoadableResource.
This is a trivial example, but it demonstrates the principle. Given that we allow you to inject a plain Java object there are many possibilities. For instance, you could read resources from a cloud storage provider, parse a bespoke configuration file format, or perhaps even prompt for user input.
Summary
That’s a brief overview of how the new API methods work. This is a fairly advanced feature which is designed to make Flyway more flexible. You can also inject a Java migration resource provider too. You can read more about the API in the documentation.
Tools in this post
You may also like
Blog
Using the new Flyway Diff commands
Blog