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

Introduce fluent configuration #1928

Closed
axelfontaine opened this issue Feb 15, 2018 · 5 comments
Closed

Introduce fluent configuration #1928

axelfontaine opened this issue Feb 15, 2018 · 5 comments

Comments

@axelfontaine
Copy link
Contributor

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");
flyway.setLocations("classpath:db/mig");
flyway.migrate();

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:

Flyway.config()
    .dataSource("jdbc:myurl", "myuser", "secretpassword")
    .locations("classpath:db/mig").load()
    .migrate();

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");
configuration.setLocations("classpath:db/mig");
Flyway flyway = new Flyway(configuration);
flyway.migrate();

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 pushed a commit to flyway/flywaydb.org that referenced this issue Feb 16, 2018
@axelfontaine
Copy link
Contributor Author

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

@axelfontaine
Copy link
Contributor Author

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

@vovkss
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: https://stackoverflow.com/questions/50845591/whats-the-officially-recommended-way-to-configure-flyway-5-1-x-programmatically

@axelfontaine
Copy link
Contributor Author

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!

@vovkss
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
Projects
None yet
Development

No branches or pull requests

2 participants