We have a multi-tenant application that uses a database per tenant. To handle database migrations, we create an instance of FlywayAutoConfiguration.FlywayConfiguration and create a Flyway instance for each tenant by calling the flyway method for each datasource. Using the FlywayAutoConfiguration allows us to use the spring.flyway properties as well as gives us support for vendor specific locations.
In Spring Boot 3.0 RC1, the flyway method now takes a ResourceProviderCustomizer as the last argument. The ResourceProviderCustomizer class is package private, preventing us from creating an instance or extending it and thereby preventing us from being able to call the flyway method.
Would it be possible to loosen the access of ResourceProviderCustomizer or to check for null in the flyway to allow a null value to be passed in?
Comment From: wilkinsona
I think that's unlikely. As described in the documentation we don't consider auto-configuration classes to be public API:
Even though auto-configuration classes are public, the only aspect of the class that is considered public API is the name of the class which can be used for disabling the auto-configuration. The actual contents of those classes, such as nested configuration classes or bean methods are for internal use only and we do not recommend using those directly.
We have considered separating our conventions from our auto-configuration but decided against doing so. Unfortunately, this sounds like a situation where that would have been useful.
Irrespective of the introduction of ResourceProviderCustomizer, I would encourage you not to depend upon FlywayConfiguration. You may want to copy-paste that code and simplify it to meet your specific needs. For example, I doubt that you need both ObjectProvider<DataSource> dataSource and @FlywayDataSource ObjectProvider<DataSource> flywayDataSource.
I'll flag this for discussion to see if we want to do anything more.
Comment From: mhalbritter
@jonyschak Would it help you if we refactored the configuration properties -> flyway mapping code into a separate class? This class would be public API and you could use it to do the properties mapping. See here for the code.
Comment From: jonyschak
Yes, that would give me exactly what I need as I won't have to keep re-syncing with any changes/enhancements spring boot makes.
Thanks!
Comment From: mhalbritter
We decided to reinstate the flyway method with the old signature but to deprecate it immediately as a signal that this should not be called. I'll create a new issue to decide if we want to extract the properties mapping logic into a public API class to ease such use cases.