Quarkus: Guess the driver from the extension selected

[emmanuelbernard]

From @gsmet
I was thinking last night about maybe having the possibility to not ask for the driver if we have only one JDBC driver present.

E.g. we could have a BuildItem created by each database extension and inject a list of them in either Agroal or the JPA processor and do some automatic things based on the number of elements we obtain.

We could also detect that we have none and throw a user-friendly error as we discussed.

It was just before going to sleep so maybe it's just a dumb idea :).

The Hibernate extension would also need to change to listen to these and not require a driver property in the case of no persistence.xml

[kenfinnigan]

We did exactly that in all versions of Thorntail, so it's not stupid and very handy

[emmanuelbernard]

@kenfinnigan wanna take a stab at it?

[kenfinnigan]

I can, but it won't be until next year most likely. No problem if someone beats me to it

[Sanne]

Warning: several JDBC jarfiles include several actual JDBC driver implementations.

That's not a blocker for this as in most cases the reason is:

• to have deprecated an old name, recommending a new one -> we pick the new one
• multiple implementations, one each for each JDBC "spec" -> we pick the right one
• different features ("XA capable" vs "simple") -> could automate (harder)
• different intended target platforms, different security mechanisms -> we pick the right one

So in principle I think this would be great, just keep in mind we'll need to somewhat hardcode some decision tables, which needs to be filled in carefully and risks getting out of date.

[gastaldi]

One solution I can see is to introduce a common module for the jdbc extensions and define a JDBCDriverBuildItem that would be produced by each quarkus-jdbc-<DB>module. Then Agroal could consume this item or use what's defined in quarkus.datasource.driver (which should take precedence).

Does that make sense?

[gsmet]

Yes, I plan to push that to some new contributors. Don't act on it please.

[emmanuelbernard]

yes that's what I had in mind

[victorl2]

I would like to start contributing with this issue, can i take it ?

[machi1990]

@gsmet I know you have been working extensively on re-writing datasource configurations, do you think @victorl2 can start working on this issue too, along side your efforts or you prefer to wait?

[Sanne]

Good point @machi1990 .

@victorl2 I think that would be great, thanks a lot for offering! But could you wait a little bit to start? @gsmet is currently finishing a significant rewrite of how the datasources are configured. He should be done in just some days, maybe next week, so probably best you wait a little to avoid a massive conflict.

[victorl2]

No problem @Sanne, i will wait until the rewrite is up.

[gsmet]

I think we could even close this ticket as you now just have to define quarkus.datasource.kind=h2 and the driver is automatically guessed (and it automatically configure a XA one if XA is enabled).

We could make the kind optional if there is only one driver but it's probably going to be a bit fragile so I would avoid that.

Hopefully, I will push a first draft of this PR tonight.

[emmanuelbernard]

Can I close it @gsmet ?

[gsmet]

We guess the driver but you still have to define the db-kind, even if you have only one driver dependency.

I prefer it this way personally, especially since there's a good chance you will have 2 in the test classpath anyway (e.g. PostgreSQL for production and H2 for the tests).

So I would rather keep it that way.

[emmanuelbernard]

Conclusion: we already guess the driver based on the database kind. Magically detecting the database kind based on the existing extension set is deemed a bit too magical. So closing this proposition.