Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JdbcMigrations and new FlywayCallback should have access to core configuration #805

Closed
pauxus opened this issue Jul 21, 2014 · 9 comments
Closed

Comments

@pauxus
Copy link
Contributor

@pauxus pauxus commented Jul 21, 2014

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.

@pauxus pauxus changed the title New FlywayCallback should include relevant migration information JdbcMigrations and new FlywayCallback should have access to core configuration Jul 25, 2014
@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Jul 25, 2014

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.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Jul 25, 2014

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
Axel

@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Jul 25, 2014

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

  • know which target environment it is running on and manage replacements themselves
  • or have access to the configuration defining the replacements

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

pauxus added a commit to pauxus/flyway that referenced this issue Jul 28, 2014
…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.
@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Sep 9, 2014

Anything new here? Did you have look at my pull request?

@rastaman
Copy link

@rastaman rastaman commented Sep 9, 2014

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...

@axelfontaine axelfontaine added this to the Flyway 4.0 milestone Sep 16, 2014
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Sep 16, 2014

This will be a breaking change, so any possible implementation will have to be deferred to Flyway 4.0

@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Sep 16, 2014

Actually, it is designed to be completely non-breaking. All additional functionality is implemented via optional interfaces.

Am 16.09.2014 um 11:40 schrieb Axel Fontaine notifications@github.com:

This will be a breaking change, so any possible implementation will have to be deferred to Flyway 4.0


Reply to this email directly or view it on GitHub.

@damonsensus
Copy link

@damonsensus damonsensus commented Sep 16, 2014

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


Reply to this email directly or view it on GitHubhttps://github.com//issues/805#issuecomment-55719167.

@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Sep 17, 2014

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.

pauxus added a commit to pauxus/flyway that referenced this issue Jan 13, 2016
…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.
pauxus added a commit to pauxus/flyway that referenced this issue Jan 15, 2016
…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.
pauxus added a commit to pauxus/flyway that referenced this issue Jan 18, 2016
…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.
pauxus added a commit to pauxus/flyway that referenced this issue Jan 19, 2016
…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.
pauxus added a commit to pauxus/flyway that referenced this issue Jan 19, 2016
…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.
pauxus added a commit to pauxus/flyway that referenced this issue Jan 19, 2016
…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.
pauxus added a commit to pauxus/flyway that referenced this issue Jan 21, 2016
…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.
pauxus added a commit to pauxus/flyway that referenced this issue Jan 21, 2016
…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.
axelfontaine added a commit that referenced this issue Jan 22, 2016
Implementation for #805: JdbcMigrations, Resolvers and FlywayCallbacks should have access to core configuration
axelfontaine added a commit that referenced this issue Jan 22, 2016
axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Jan 22, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.