Flyway Build Item (prerequisite for multitenant extension)

[rmanibus]

• Create Flyway build item to allow other extensions to create flyway instances
• Allow multiple flyway instances by datasources (add unique id attribute that is not the ds name)
• move startAction in flyway container to allow other extension to define different behavior

[rmanibus]

cc @geoand

[github-actions]

🎊 PR Preview b46c8ef has been successfully built and deployed to https://quarkus-pr-main-43892-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.

[geoand]

Nice!

I'll have a close look in the following days, but I see that CI is not happy.
I see this in the logs:

Run ./update-extension-dependencies.sh and add the modified pom.xml files to your commit.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 5c8b85a.

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

[rmanibus]

not sure about the naming of this one

[geoand]

@gastaldi @gsmet what is your opinion on having this here in the core vs Quarkiverse?

We have been trying hard to limit the number of extensions going into the core repo, but IMHO this is one is not totally a clear cut decision.

[gastaldi]

Not sure a separate extension for this is necessary: It looks like this feature can be implemented in the quarkus-flyway extension directly by making the io.quarkus:quarkus-hibernate-orm an optional dependency.

[geoand]

That's a good idea!

[geoand]

Conditional dependencies might also make sense

[rmanibus]

I will try to explore this option.
Should I keep both config isolated ?

It does not feel right to mix flyway instances tied to data sources and others tied to persistence units

[geoand]

It does not feel right to mix flyway instances tied to data sources and others tied to persistence units

I'll defer this one to @yrodiere who has thought a lot about Datasources and their configuration

[gastaldi]

I will try to explore this option. Should I keep both config isolated ?

Yes, that makes sense

[yrodiere]

It does not feel right to mix flyway instances tied to data sources and others tied to persistence units

I'll defer this one to @yrodiere who has thought a lot about Datasources and their configuration

Not a fan of the approach either. I'd much rather we fixed the root of the problem: #11861
Then you'll have a much easier way to integrate Flyway in multi-tenant scenarios.

But, well. Someone needs to work on #11861.

[rmanibus]

Well , I could have a look into this one too.
The only issue is that I need a solution for this asap.

Until this is done, since tenancy has been coupled with PU forever, could it be ok to still have flyway instances coupled to PU as introduced in this PR in an entirely different namespace (this PR uses quarkus.flyway.multitenant, but it could also be quarkus.flyway.hibernate) ?

[yrodiere]

Well , I could have a look into this one too.

That would be great, thank you!

The only issue is that I need a solution for this asap.

Until this is done, since tenancy has been coupled with PU forever, could it be ok to still have flyway instances coupled to PU as introduced in this PR in an entirely different namespace (this PR uses quarkus.flyway.multitenant, but it could also be quarkus.flyway.hibernate) ?

Adding something like this to Quarkiverse is always an option, for sure.

To the core repo... I doubt it. For something urgent and temporary, Quarkiverse would be better IMO. But then it's not like my approval is needed to add extensions to Quarkus :)

[rmanibus]

sure, but it would ideally still requires some change in the core repo, mainly to expose the flyway build item that does not exist today

[rmanibus]

should I reduce the scope of this PR to the changes introduced in the main flyway extension and then move everything from the flyway-multitenant in the quarkiverse ?

[yrodiere]

sure, but it would ideally still requires some change in the core repo, mainly to expose the flyway build item that does not exist today

should I reduce the scope of this PR to the changes introduced in the main flyway extension and then move everything from the flyway-multitenant in the quarkiverse ?

Fine by me. @geoand ?

[geoand]

+1

[rmanibus]

@geoand I cleaned up this PR, what do you think ?

[rmanibus]

Seeing the complexity of the build item, I am wondering if it is a good idea to try to reuse the logic from the flyway extension. It might be simpler just to create the multi tenancy extension from scratch

[geoand]

I will take a better look at your changes next week to see what's involved and let you know