JdbcMigrations and new FlywayCallback should have access to core configuration #805
Comments
pauxus
changed the title
|
Actually, the same holds true for Java based migrations (Jdbc and SpringJdbc). Since they only get access to a connection, they have no information about replacements or used schemas. To maintain backward compatibility, I propose introducing a new Interface ConfigurationAware, which can be attached to Migrations, Resoilvers and Callbacks. When this interface is present (only containing a setFlywayConfiguration method), the current flyway configuration would automatically be injected. I am currently working on an implementation for this, right now it works, but has still some rough edges. |
|
What is your exact situation that drives this need? Please help me understand so I can get a better feel for the type of problem needing to be solved. Cheers |
|
In our case we use (for historical and organizational reasons) different schemas for prod, int and dev machines. Which of course is no problem, since flyway supports replacements. For some complex migrations, we need to make use either of stored procedures (yieks), or do them in a clean java migration. For our migration to work in all environments, it needs to either
With the second solution, we can stay simple and and clean and we do not need to repeat configuration elements. The same holds true for after migration steps (runstats reorg in our case), which I would like to put in a couple of sql scripts to be run by a custom callback. However, these scripts also need to know about replacements. I think some other core configurations could also be useful for migrations (the used schemas themselves), so I suggest providing the complete configuration. Cheers, Stephan |
…to core configuration Introduced a generic ConfigurationAware interface. This allows to inject Core configuration into resolvers, migrations and callbacks. Configuration is injected by using a new FlywayConfiguration interface, which provides read only access to flyway configuration. Right now, Flyway implements FlywayConfiguration directly.
|
Anything new here? Did you have look at my pull request? |
|
Hi all, Thanks for this wonderful tool! I also need the feature proposed in this issue, is there any estimate on when a release will incorporate it ? I've reported the pull request code in my local copy of Flyway and will use it, but i would prefer to use an "official" release. Thanks, PS: In my case it is just to concatenate all the SQL files in a big file to send to production. (they didn't want to use flyway) I have the names of the migration files with the FlywayCallback but no other info like where are stored the files,etc... |
|
This will be a breaking change, so any possible implementation will have to be deferred to Flyway 4.0 |
|
Actually, it is designed to be completely non-breaking. All additional functionality is implemented via optional interfaces.
|
|
Of course, for 3.x, you could simply expose the core config via a singleton. Sent from my iPhone On Sep 16, 2014, at 3:40 AM, "Axel Fontaine" <notifications@github.commailto:notifications@github.com> wrote: This will be a breaking change, so any possible implementation will have to be deferred to Flyway 4.0 — |
|
Using a singleton would pose some dangers. If a project uses more than one flyway instance to perform different migrations (for example to two databases), this could go seriously wrong. Injection is much safer. |
…to core configuration Introduced a generic ConfigurationAware interface. This allows to inject Core configuration into resolvers, migrations and callbacks. Configuration is injected by using a new FlywayConfiguration interface, which provides read only access to flyway configuration. Right now, Flyway implements FlywayConfiguration directly.
…he current DbSupport instance This is necessary to fully replace the default resolvers (for example with a customized subclass). This also changes the handling between CompositeMigrationResolver and the three default resolvers. Previously, the CMR created a new instance of each default resolver for every location. After this change, only one Instance of each resolvers is created which iterates the locations by itself. This is more consistent with custom resolvers, which also would have to iterate through all locations by themselves.
…he current DbSupport instance This is necessary to fully replace the default resolvers (for example with a customized subclass). This also changes the handling between CompositeMigrationResolver and the three default resolvers. Previously, the CMR created a new instance of each default resolver for every location. After this change, only one Instance of each resolvers is created which iterates the locations by itself. This is more consistent with custom resolvers, which also would have to iterate through all locations by themselves.
…to core configuration Introduced a generic ConfigurationAware interface. This allows to inject Core configuration into resolvers, migrations and callbacks. Configuration is injected by using a new FlywayConfiguration interface, which provides read only access to flyway configuration. Right now, Flyway implements FlywayConfiguration directly.
…to core configuration Introduced a generic ConfigurationAware interface. This allows to inject Core configuration into resolvers, migrations and callbacks. Configuration is injected by using a new FlywayConfiguration interface, which provides read only access to flyway configuration. Right now, Flyway implements FlywayConfiguration directly.
…to core configuration Introduced a generic ConfigurationAware interface. This allows to inject Core configuration into resolvers, migrations and callbacks. Configuration is injected by using a new FlywayConfiguration interface, which provides read only access to flyway configuration. Right now, Flyway implements FlywayConfiguration directly.
…to core configuration Introduced a generic ConfigurationAware interface. This allows to inject Core configuration into resolvers, migrations and callbacks. Configuration is injected by using a new FlywayConfiguration interface, which provides read only access to flyway configuration. Right now, Flyway implements FlywayConfiguration directly.
…to core configuration Introduced a generic ConfigurationAware interface. This allows to inject Core configuration into resolvers, migrations and callbacks. Configuration is injected by using a new FlywayConfiguration interface, which provides read only access to flyway configuration. Right now, Flyway implements FlywayConfiguration directly.
Implementation for #805: JdbcMigrations, Resolvers and FlywayCallbacks should have access to core configuration
…o core configuration (minor cleanup)
Right now, the new FlywayCallback mechanism is usefull, but limited. What it is lacking is access to Placeholder information, at least.
What I propose is:
Give the callbacks access to the Placeholder (either using a forced constructor via an abstract class, a setter or some form of dependency injection).
Or give the callback access to the main Flyway instance (or a readonly wrapper around it).
That way, a callback could make use of all configurations done via property files or any other launch mechanism.
The text was updated successfully, but these errors were encountered: