quarkus: Cannot use Liquibase extension with hibernate-reactive

Current workaround is based on the workaround from @gwenneg on this issue #10716:

        @ConfigProperty(name = "custom.liquibase.migrate")
	boolean runMigration;
	@ConfigProperty(name = "quarkus.datasource.jdbc.url")
	String datasourceUrl;
	@ConfigProperty(name = "quarkus.datasource.username")
	String datasourceUsername;
	@ConfigProperty(name = "quarkus.datasource.password")
	String datasourcePassword;
        @ConfigProperty(name = "quarkus.liquibase.change-log")
	String changeLogLocation;

	public void runLiquibaseMigration(@Observes StartupEvent event) throws LiquibaseException {
		if(runMigration)
		{
			Liquibase liquibase = null;
			try {
				ResourceAccessor resourceAccessor = new ClassLoaderResourceAccessor(Thread.currentThread().getContextClassLoader());
				DatabaseConnection conn = DatabaseFactory.getInstance().openConnection(datasourceUrl, datasourceUsername, datasourcePassword, null, resourceAccessor);
				liquibase = new Liquibase(changeLogLocation, resourceAccessor, conn);
				liquibase.update(new Contexts(), new LabelExpression());
			} catch (Exception e) {
				logger.error("Liquibase Migration Exception: " + ExceptionUtil.generateStackTrace(e));
			}
			finally {
				if(liquibase!=null)
				{
					liquibase.close();
				}
			}
		}
	}

application.properties:

quarkus.datasource.db-kind=postgresql
quarkus.datasource.username={username}
quarkus.datasource.password={password}
quarkus.datasource.jdbc=false
quarkus.datasource.jdbc.url=jdbc:postgresql://{db-url}
quarkus.datasource.reactive.url=vertx-reactive:postgresql://{db-url}
quarkus.hibernate-orm.log.sql=true
quarkus.liquibase.change-log=db/changeLog.xml
custom.liquibase.migrate=true

pom.xml dependencies tag:

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-hibernate-reactive</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-resteasy-reactive-jackson</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-resteasy-reactive</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-reactive-pg-client</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-arc</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-hibernate-validator</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-liquibase</artifactId>
    </dependency>
    <dependency>
        <groupId>io.quarkus</groupId>
        <artifactId>quarkus-jdbc-postgresql</artifactId>
    </dependency>

There’s definitely something broken and I think the main culprit is that we should split Hibernate ORM/Hibernate Reactive differently and have:

• a common extension that doesn’t enable any features by itself and just provide common code
• hibernate-orm that depends on the common extension
• hibernate-reactive that depends on the common extension instead of having the hibernate-reactive extension depending on hibernate-orm.

This way, you could have a JDBC driver around without automatically triggering Hibernate ORM. That’s the main problem you all have here.

We also might need separate config roots or a way to define if a PU is reactive or not.

But given @Sanne is currently working on integrating ORM 6 and that it will probably be a big change, this work would need to be done after ORM 6 has landed.

Maybe a warning on the Liquibase and Flyway guides that they do not work with Hibernate Reactive by default will be a good idea.

@BlackSharkCZE Several workarounds have been suggested or linked in this discussion. These workarounds make it possible to use Liquibase alongside with Hibernate Reactive in most projects.

Do you have a blocking problem that can’t be solved with one of these? If so, don’t hesitate to give us more details. The community might be able to help you fix it.

Are there any plans to introduce liquibase and flyway as reactive variant? I know the problems can be solved using a workaround, but reactive being the default now, a workaround feels a bit meh… It would be so cool to get rid of the jdbc dependency, the manual configuration and the warning in the console 2022-07-20 10:03:52,811 WARN [io.quarkus.agroal.deployment.AgroalProcessor] (build-33) The Agroal dependency is present but no JDBC datasources have been defined..

@BlackSharkCZE Several workarounds have been suggested or linked in this discussion. These workarounds make it possible to use Liquibase alongside with Hibernate Reactive in most projects.

Do you have a blocking problem that can’t be solved with one of these? If so, don’t hesitate to give us more details. The community might be able to help you fix it.

IIRC, @Sanne has mentioned elsewhere that this issue will be addressed, but likely after Hibernate 6 is out and integrated into Quarkus.

https://github.com/quarkusio/quarkus/issues/10716#issuecomment-1022118053

Sure, booting Hibernate Reactive on your own is of course possible.

But it’s not integrated into Spring in any way, nor is there any integration with Flyway or Liquibase that could be used to claim that the same feature exists in Spring and not Quarkus.

My whole point is that Quarkus is at the bleeding edge of innovation and this highly requested feature will definitely land at some point, it’s just a matter of priorities

To be completely fair, there is no Hibernate Reactive in Spring…

IIRC, @Sanne has mentioned elsewhere that this issue will be addressed, but likely after Hibernate 6 is out and integrated into Quarkus.

Any progress on this issue? Feels pretty odd coming from Spring and experiencing such issues from the very beginning 😢

DatabaseFactory

Just as a hint that may help:

• Liquibase will try to guess the database type from the url , but the url you provided is not supported : jdbc:otel:postgresql , that is why it fails.
• to solve this, I guess you just have to provide both the url’s to your application , each on different property.
• use quarkus.datasource.jdbc.url=jdbc:otel:postgresql://localhost:5432/telemetry for the application , and another property for getting connections for liquibase : com.myapp.liquibase.datasource.jdbc.url=jdbc:postgresql://localhost:5432/telemetry

then in you LiquibaseRunner :

@ConfigProperty(name = "com.myapp.liquibase.datasource.jdbc.url")
    String datasourceUrl;

Hi, this is my solution…

build.gradle.kts

    //for application runtime   
    implementation("io.quarkus:quarkus-hibernate-reactive-panache")
    implementation("io.quarkus:quarkus-reactive-mysql-client")

    //only for liquibase migration
    implementation("io.quarkus:quarkus-jdbc-mysql")
    implementation("io.quarkus:quarkus-liquibase")

application.properties (I used default dev configs: https://quarkus.io/guides/databases-dev-services)

quarkus.devservices.enabled=true
quarkus.datasource.devservices.enabled=true

quarkus.datasource.db-kind=mysql
quarkus.datasource.jdbc=false

quarkus.hibernate-orm.database.generation=none

quarkus.liquibase.custom-migrate=true
quarkus.liquibase.migrate=false
quarkus.liquibase.change-log=db/changeLog.xml

a LiquibaseSetup.kt class

@ApplicationScoped
class LiquibaseSetup {

    @ConfigProperty(name = "quarkus.liquibase.custom-migrate")
    var runMigration = false

    @ConfigProperty(name = "quarkus.datasource.reactive.url")
    lateinit var datasourceUrl: String

    @ConfigProperty(name = "quarkus.datasource.username")
    lateinit var datasourceUsername: String

    @ConfigProperty(name = "quarkus.datasource.password")
    lateinit var datasourcePassword: String

    @ConfigProperty(name = "quarkus.liquibase.change-log")
    lateinit var changeLogLocation: String

    fun runLiquibaseMigration(@Observes event: StartupEvent) {
        if (runMigration) {
            var liquibase: Liquibase? = null
            try {
                Log.info("liquibase setup to $datasourceUrl")
                val resourceAccessor: ResourceAccessor = ClassLoaderResourceAccessor(Thread.currentThread().contextClassLoader)
                val conn: DatabaseConnection = DatabaseFactory.getInstance().openConnection(
                        datasourceUrl.replace("vertx-reactive", "jdbc"),
                        datasourceUsername,
                        datasourcePassword,
                        null,
                        resourceAccessor
                    )
                liquibase = Liquibase(changeLogLocation, resourceAccessor, conn)
                liquibase.update(Contexts(), LabelExpression())
            } catch (e: Exception) {
                Log.error("Liquibase Migration Exception: ", e)
            } finally {
                liquibase?.close()
            }
        }
    }
}

Agreed. Sorry people, will have to be patient as the switch to Jakarta takes priority and some “projects” are better not run in parallel.

In the meantime I would suggest embrace strict separations of concerns: don’t include Flyway in the same application as Hibernate Reactive.

I do appreciate that such a solution is not always very practical, but I do believe it’s the better design as you wouldn’t ship Flyway in production and won’t need 100s of copies of flyway to run when scaling production up/down. This way you can benefit from both Flyway and Hibernate Reactive today, and using the robust and well tested existing processes.

Totally understandable 💯, thanks for the effort!