You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we have the FlywayConfiguration it might be useful to be able to pass an implementation of that interface to Flyway to complete it as a whole (Flyway.copyConfigurationFrom(FlywayConfiguration) or Flyway.setConfiguration(FlywayConfiguration)).
This would allow to directly set the configuration from different models like the Maven Plugin, a Gradle extension or a DevOps Model, effectively reducing effort and risk when introducing new options.
In our specific use case, we have most Flyway specific configuration (like JDBC url and credentials) in a Klum based Model anyway. Currently, we convert the model manually into a flyway configuration, but this seems rather unnecessary. Most of the Flyway code uses the Configuration object already.
There are IMHO two possible approaches to this:
Quick and (somewhat) dirty: move the copy statements into the the new copyFromConfiguration() method
refactor the actual configuration data in Flyway into a new class DefaultFlywayConfiguration and delegate all access to confiuration data in Flyway to that new instance. Flyway could then pass that instance instead of this to all subsystems
Both approaches should be completely backward compatible.
I think the second approach is nicer from a SOC point of view, as it allows all configuration related code to get its own place.
I can create a pull request for that.
The text was updated successfully, but these errors were encountered:
Since we have the
FlywayConfiguration
it might be useful to be able to pass an implementation of that interface toFlyway
to complete it as a whole (Flyway.copyConfigurationFrom(FlywayConfiguration)
orFlyway.setConfiguration(FlywayConfiguration)
).This would allow to directly set the configuration from different models like the Maven Plugin, a Gradle extension or a DevOps Model, effectively reducing effort and risk when introducing new options.
In our specific use case, we have most Flyway specific configuration (like JDBC url and credentials) in a Klum based Model anyway. Currently, we convert the model manually into a flyway configuration, but this seems rather unnecessary. Most of the Flyway code uses the Configuration object already.
There are IMHO two possible approaches to this:
DefaultFlywayConfiguration
and delegate all access to confiuration data in Flyway to that new instance. Flyway could then pass that instance instead ofthis
to all subsystemsBoth approaches should be completely backward compatible.
I think the second approach is nicer from a SOC point of view, as it allows all configuration related code to get its own place.
I can create a pull request for that.
The text was updated successfully, but these errors were encountered: