Hibernate reactive + Flyway extension causes UnsatisfiedResolutionException #10716
Comments
quarkusbot
added
area/hibernate-orm
|
/cc @aguibert, @gavinking, @Sanne |
|
Interesting. Do you have a small reproducer showing this problem? I assume if it's just adding as simple as adding |
|
Actually, this doesn't seem like a bug to me... Flyway requires that a blocking driver be present and the Hibernate Reactive Quickstart doesn't use one. |
|
The reproducer is the quickstart steps. So its a design choice to limit Hibernate Reactive from using Flyway? Even if Hibernate Reactive doesn't use it, what prevents it from just ignoring that blocking one (and let just Flyway use it) ? Kinda defeats the point of quarkus-flyway if it doesn't work with any async db extensions. |
As for using |
|
Yes, I had a working flyway installation in my own project. I tried adding hibernate-reactive to it but that started the issues, the quickstart modification was just a reproducer. |
|
OK, but the way you mention to reproduce the issue doesn't surface that concern. Let me try something else and get back to you |
|
Okay, my bad. I see that just adding So yeah, it's definitely an issue, quarkus-hibernate-reactive shouldn't be blocked from starting just by the presence of |
|
@Sanne, @aguibert @gsmet this ultimately comes down to the fact that So it seems to me that in order to fix this, we need some more clever way of interacting between the datasource configuration and hibernate extensions code. |
I agree, that's what I had in mind to do. I suppose I got confused with things while working on the previous fix. |
|
I can confirm this issue also exists for quarkus-liquibase. Is there a way to work around this for the time being? |
|
@Sanne Is there a way to work around this issue until a fix is included into a Quarkus release? |
|
By "this issue", I don't mean the |
|
Hi @gwenneg , I'm not sure yet about a clever workaround - I need to have a better look, I'll start with this on Monday. The core of the issue is that both ORM blocking and non-blocking are being triggered for initialization and there's a confusing mix of services being shared among them. In terms of quick workarounds - would you be able to keep Flyway in a separate application? I've always wondered how far this belongs in the same deployment unit; for example it should be easy to have an app module which does take care of the migration, and a different app module which just boots on the migrated DB. It certainly would be more "minimal". |
|
Thanks for your help on this one! Keeping Flyway in a separate application could work indeed. I have a different kind of solution which seems to work fine in JVM mode (not so sure about native mode but I don't need it for now): I wish I could keep |
|
@gwenneg: How does your application.properties look like? I tried your code but I still get an error that the |
|
It looks to me that hibernate-reactive/reactive-postgres checks if the |
|
@andreas-eberle My The |
|
@gwenneg. Thanks a lot!! We would have never thought of that! |
|
The reason is that in early days a datasource couldn't be both jdbc and reactive, and the Hibernate would look at what kind of datasource was configured to decide to boot as Hibernate ORM vs as Hibernate Reactive. Until recently the integration of Hibernate Reactive was a POC taking advantage of some simplied assumptions; among these: if you're using Hibernate Reactive there won't be any blocking JDBC-based stuff. Clearly that's naive, but was considered acceptable as we focused on maturing the core of Hibernate Reactive. Now that a single datasource can be both reactive and blocking, and we can have multiple datasource with different configurations, we need to correct the assumptions that the extension is making; we'll probably need some explicit way for users to choose what kind of Hibernate they want - however I'd love it if we could infer this automatically, provided it can be done in a robust and non-suprising way. I'm open to suggestions :) Same basic draft:
Currently the Hibernate Reactive extension depends on the blocking one, so if the Hibernate Reactive extension is missing it's easy: no hibernate reactive will start - but the opposite isn't true. I propose this is fine initially, we can refine the automatic guess in the future, as we could evolve the Hibernate Reactive extension to no longer depend on the blocking ORM extension. More importantly, some other extensions use the JPA service while not using annotations to define injection points; for example if such other extension should perform programmatic lookup of Interestingly it seems |
|
I'd like to suggest to only have a single |
FTR: #14682 |
I have explained in the code, you need to specify manually with a list. |
This is what I use in my application: https://gist.github.com/seeseemelk/27c601ad8ce5a6a89d423a476d6e9237 |
Could you be sure that it will work under native as well? |
Can I see your application.properties? Do you have to list all migration files individually? |
|
Good point, I completely forgot about the application.properties. |
|
Hi. What's the state of this issue? We're evaluating the adoption of Quarkus in my company but this issue seems a key question: we have no way to avoid DB migrations and reactive seems one of the flagships of Quarkus. How is it suppose we could move on without giving-up on one? I am skeptic to go on with the workaround for a production ready product. At least, is there any timeline for this to be fixed? |
@cdmikechen Yes, I did make native image and this workaround works there too. |
Looks like with new versions coming up, it does not work. My quarkus version is With above configurations mentioned , it throws following error
is there a specific version I should stick to ? Thanks |
|
Hello, @Sanne , the exception seems not the same, do you think it should be handled in the same issue ? Seems it involve different components and some assumptions should be reviewed for the hibernate reactive part. Thanks |
|
We also hit this issue recently and came up with relative clean solution. We follow the approach from above, but also make sure everything works nicely in dev mode and production.
@Startup
public class FlywayMigration {
FlywayMigration(Scheduler scheduler,
FlywayConfig flywayConfig,
SessionFactory sessionFactory,
@ConfigProperty(name = "quarkus.datasource.reactive.url") String datasourceUrl,
@ConfigProperty(name = "quarkus.datasource.username") String datasourceUsername,
@ConfigProperty(name = "quarkus.datasource.password") String datasourcePassword) {
Flyway flyway = Flyway
.configure()
.dataSource(datasourceUrl.replace("vertx-reactive:", "jdbc:"), datasourceUsername, datasourcePassword)
.cleanDisabled(!flywayConfig.clean())
.load();
if (flywayConfig.migrateAtStart()) {
scheduler.pause();
if (flywayConfig.cleanAtStart()) {
flyway.clean();
}
flyway.migrate();
sessionFactory.getSchemaManager().validateMappedObjects();
scheduler.resume();
}
}
@ConfigMapping(prefix = "application.database.flyway")
public interface FlywayConfig {
boolean migrateAtStart();
@WithDefault("false")
boolean cleanAtStart();
}
}For this you need the following extensions: <dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-flyway</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-hibernate-reactive</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jdbc-postgresql</artifactId>
</dependency>
<!-- Optional -->
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-scheduler</artifactId>
</dependency>We have the following config values set: And in dev mode we set |
|
The fix was released in 3.5, but I still need to do the workaround described above . Do I need to have the workaround described? What properties should I have to have Hibernate reactive and flyway working at the same time? |
|
@miguelborges99 We have a (simple) integration test that works with this configuration. Several things to take care about:
If you still encounter problems, can you please open another issue with a reproducer? Thank you. |
|
Hi @yrodiere , Thanks |
Yes, and that's documented here: https://quarkus.io/guides/hibernate-reactive#hr-limitations
It seems the Hibernate Reactive extension for Quarkus doesn't support multi-tenancy at the moment: #15959 "static" configuration with named datasources certainly won't work due to this limitation. A more dynamic approach where you create your own connections could work in theory, but I'm pretty sure it won't in practice because of the missing configuration mentioned in #15959. Schema-based multitenancy is more likely to work to with Hibernate Reactive, FWIW. Though I'm not entirely sure either, since this I couldn't find relevant tests. |
|
Thanks for the quick reply, i will continue the discussion on : #33342 |
|
The solution provided in the thread to set |
|
Hello all, I ran into the same Issue not being able to use flyway migration in combination with a reactive data source. The workaround above works fine for me (running flyway manually on application startup). Just FYI: I constantly got exceptions when I open the Quarkus DEV UI: I fixed that by removing the Cheers |
This was supposed to be fixed in #36012, in Quarkus 3.5.0.CR1. Can you please open a new issue with a reproducer?
This looks like a bug too. Let's see what your reproducer looks like though, there must be something else at play. |
|
Hi guys `quarkus.datasource.db-kind = postgresql quarkus.flyway."flyway-migration".active = true |
|
Hey, FWIW you don't need two datasources, so the right configuration would be something like this: Or this if you use dev services: I updated the documentation to make this clearer: https://quarkus.io/version/main/guides/flyway#reactive-datasources |
|
Hi @yrodiere - I'm a recent victim of this scenario as well. I need Flyway working for local development and for other environments as well. Setting Prevented Flyway from working locally for me. Is that expected? My final configuration looks like But now I fear that Hibernate Reactive does not use the correct reactive driver anymore (since JDBC is not disabled). Does this look correct to you? Thanks! |
|
Hello
Yes. Flyway uses JDBC. You disable JDBC, Flyway doesn't work.
Then fear not: Hibernate Reactive is absolutely incapable of using JDBC.
Yes. |
and others
Describe the bug
Simply adding the
quarkus-flywayextension when using Hibernate Reactive causes:Expected behavior
Flyway should be usable in an application that uses the hibernate-reactive extension.
Actual behavior
Will not start.
To Reproduce
Steps to reproduce the behavior:
Environment (please complete the following information):
java -version: openjdk version "11.0.7" 2020-04-14Additional context
(Add any other context about the problem here.)
The text was updated successfully, but these errors were encountered: