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

Introduce fluent configuration #1928

axelfontaine opened this Issue Feb 15, 2018 · 5 comments


None yet
2 participants
Copy link

axelfontaine commented Feb 15, 2018

Flyway's configuration currently relies on JavaBean-style properties of the main Flyway class. For example:

Flyway flyway = new Flyway();
flyway.setDataSource("jdbc:myurl", "myuser", "secretpassword");

While having the advantage of being simple, it also comes at a cost: mutability. This makes it harder to perform certain kind of optimizations.

To remedy this Flyway 5.1 will introduce a new fluent configuration style which looks as follows:

    .dataSource("jdbc:myurl", "myuser", "secretpassword")

This has the advantage of being slightly more concise, while presenting Flyway with an immutable FlywayConfiguration instance to work with.

This style should be the preferred style going forward for API usage.

For older technologies like Spring XML bean configuration, this however isn't a great fit. We are therefore also introducing ClassicConfiguration which also offers the same runtime immutability benefits, while preserving the JavaBean-style methods:

ClassicConfiguration configuration = new ClassicConfigution();
configuration.setDataSource("jdbc:myurl", "myuser", "secretpassword");
Flyway flyway = new Flyway(configuration);

The original get and set methods from the Flyway class will be deprecated and marked for removal as part of the Flyway 6.0 release. With Flyway 6.0, the Flywayclass itself will also no longer implement the FlywayConfiguration interface.

At that point we'll be able to fully take advantage of the immutability and the optimisation opportunities it offers.

@axelfontaine axelfontaine added this to the Flyway 5.1.0 milestone Feb 15, 2018

axelfontaine added a commit to flyway/ that referenced this issue Feb 16, 2018

axelfontaine added a commit that referenced this issue Apr 6, 2018


This comment has been minimized.

Copy link

axelfontaine commented Apr 6, 2018

We decided to back this out as it wasn't pulling its conceptual weight.


This comment has been minimized.

Copy link

axelfontaine commented May 17, 2018

Backed out the backout. FluentConfiguration is back in the public API.


This comment has been minimized.

Copy link

vovkss commented Jun 13, 2018

The snippet above doesn't compile, but this works:

    final var flywayConfiguration = new FluentConfiguration()
        .dataSource(url, user, password);
    new Flyway(flywayConfiguration).migrate();

Can you please confirm if this is the correct and recommended API usage for 5.1.1 and above?

P.S. also included this as a question on Stack Overflow:


This comment has been minimized.

Copy link

axelfontaine commented Jun 14, 2018

These Configuration changes are part of a larger overall story, in order to make Flyway instances immutable. Additional parts will be delivered in 5.2.

For now you have the choice, between the code as you presented it, and the existing setter-based approach.

In 5.2 we expect to add the static Flyway.config() method from the original example and then we'll probably start deprecating the setter based approach soon after.

We opted for this phased approach to gather feedback along the way. Even though this may not seem like much, it does impact every article and every piece of documentation ever written about the Flyway API, so we are threading very carefully here.

So if you do have feedback or remarks, now is the time. Please send them our way!


This comment has been minimized.

Copy link

vovkss commented Jun 14, 2018

So I personally like the new way, as the whole configuration+migration procedure can be accomplished as a single statement and requires less code (skipping flywayConfiguration.set for every configuration option).

Other improvements are great as well — e.g. .encoding(...) accepting Charset instead of String and overloaded .baselineVersion(String) (instead of baselineVersionAsString()) — but some of these are now available in ClassicConfiguration as well.

Thanks for the clarification!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment