Remove cleanOnValidationError config in Flyway

[gastaldi]

Starting in Flyway 11.0.0 (see https://documentation.red-gate.com/flyway/release-notes-and-older-versions/release-notes-for-flyway-engine), the cleanOnValidationError function and configuration has been removed.
An error will be thrown if this feature is configured.

Therefore it is better to remove this configuration from Quarkus so applications using it would fail as well (instead of deprecating it).

• Added to migration guide as well: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.18#cleanonvalidationerror-configuration-removed
• Added to update script: Introduce Quarkus 3.18 Migration Scripts quarkus-updates#231

[github-actions]

🎊 PR Preview 6a487f0 has been successfully built and deployed to https://quarkus-pr-main-44912-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 58f6144.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 58f6144.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[geoand]

That's weird as the code clearly still has the method and configuration... Nevermind I actually tried it and it fails when used

[gsmet]

I wonder if it's not a bit premature to drop the configuration property.

Quarkus won't fail if the property doesn't exist, it will just log a warning - which is easy to miss.

I wonder if we should deprecate the property instead, at least for a few versions and let it be a hard fail on the Flyway side. At least until they completely drop the method we are using (my understanding is that the code compiles but will throw an error for now).

[geoand]

What would be the benefit?

[gastaldi]

@gsmet I pondered about that, but because setting the configuration fails the app startup, I don't think it's safe to have it around anymore

[gsmet]

Well, is it safer to completely ignore it and that the user is not aware at all that the config property is not doing anything anymore?

Because between this PR and the update recipe, the user has absolutely no chance to figure out this option is not available anymore.

My personal conviction is that we should at least have a release where we have the big failure before dropping it so that people have a chance to notice and adjust by themselves/find a workaround.

Now maybe I'm being too cautious and this config property is not critical enough but with data, you need to be extra safe.

[gastaldi]

Well, is it safer to completely ignore it and that the user is not aware at all that the config property is not doing anything anymore?

I am not sure, IMHO deprecating the config property would give a false illusion that the feature still works and the user can keep using it, which is no longer true.

Because between this PR and the update recipe, the user has absolutely no chance to figure out this option is not available anymore.

I am hoping that the Migration Guide would let them know about it: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.18#cleanonvalidationerror-configuration-removed

[geoand]

I am not sure, IMHO deprecating the config property would give a false illusion that the feature still works and the user can keep using it, which is no longer true.

That's my thinking as well