/cc @Sanne (hibernate-orm), @gsmet (hibernate-orm)

Hello @yrodiere I tried to look into this issue but without any luck. Can you provide some more details how to reproduce that? I am also wondering about your thoughts on this one, right now it seems that maybe we should remove this dialect setting explicitly (to satisfy hibernate) and see if this works. But I don't know if this is good thing to do - first I would like to see this myself, investigate and hopefully come with some solution proposition :)

Hey @MaciejDromin
you could try building one of the test modules that has ORM + Postgres in native mode, for example:

mvn clean install -Dtest-containers -Dstart-containers -Dnative -pl :quarkus-integration-test-jpa-postgresql

then you'll see the log entries during the native build:

-----------------------------------------------------------------------------------------------------------------------
Build resources:
 - 22.79GB of memory (36.4% of 62.54GB system memory, determined at start)
 - 24 thread(s) (100.0% of 24 available processor(s), determined at start)
15:18:05,418 WARN  [org.hib.orm.deprecation] HHH90000025: PostgreSQLDialect does not need to be specified explicitly using 'hibernate.dialect' (remove the property setting and it will be selected by default)
15:18:05,547 WARN  [org.hib.orm.deprecation] HHH90000025: PostgreSQLDialect does not need to be specified explicitly using 'hibernate.dialect' (remove the property setting and it will be selected by default)
[2/8] Performing analysis...  [*****]           

To make it easier to debug, you can just run a test from that module and see when https://github.com/hibernate/hibernate-orm/blob/f4f62c81fa5c877a907f8fa587798f805ee374c6/hibernate-core/src/main/java/org/hibernate/engine/jdbc/dialect/internal/DialectFactoryImpl.java#L153 is reached.
Then I'd suggest to probably start from taking a look at the HibernateOrmProcessor, this line in particular:

In general, ORM should be able to figure out the dialect itself from other info unless a user needs a custom dialect (see [1]). So maybe you could start by not setting the dialect and see where it takes you?

[1] https://docs.jboss.org/hibernate/orm/6.4/introduction/html_single/Hibernate_Introduction.html (2.6. Basic configuration settings)

Hey @marko-bekhta Thanks for the clues and some more insight into this issue!

So maybe you could start by not setting the dialect and see where it takes you?

I will try that and see what will happen. I hope to take a look into this issue in the following days

In general, ORM should be able to figure out the dialect itself from other info unless a user needs a custom dialect (see [1]). So maybe you could start by not setting the dialect and see where it takes you?

Careful about that. This was supposedly true when I wrote that code, too, but I ended up having to set the dialect explicitly anyway. I don't remember why, unfortunately :/ I think it was something like Hibernate ORM not auto-detecting dialects when we set hibernate.temp.use_jdbc_metadata_defaults to true (which we absolutely need to do during the build).

(That said, this is definitely the first step into investigating the problem. I'm just saying the solution may be more complex, or at least involve more tests).

Careful about that. This was supposedly true when I wrote that code, too, but I ended up having to set the dialect explicitly anyway. I don't remember why, unfortunately :/ I think it was something like Hibernate ORM not auto-detecting dialects when we set hibernate.temp.use_jdbc_metadata_defaults to true (which we absolutely need to do during the build).

I checked that and you are right, dialect is not auto-detected when hibernate.temp.use_jdbc_metadata_defaults is set to true. From what I observed there is no jakarta.persistence.jdbc.url property alongside credentials passed there, I'm not sure why and I believe that may be the reason. Maybe if we somehow convert quarkus.persistence.jdbc.url to this config property so it will be resolved it may help?

From what I observed there is no jakarta.persistence.jdbc.url property alongside credentials passed there, I'm not sure why and I believe that may be the reason.

We can't pass a JDBC URL at that point. This code gets executed at build time, and the JDBC URL is a runtime property. It's perfectly valid for it to not be set at build time.

Now, this is beginning to look like an incorrect behavior in Hibernate ORM;

1. If it can auto-detect the dialect when hibernate.temp.use_jdbc_metadata_defaults is set to true, then it should.
2. If it can't auto-detect the dialect, it should not issue a warning.

If we're in case 2, the (temporary) solution to this issue might be to simply hide the warning, like we already do for other logs in io.quarkus.hibernate.orm.deployment.HibernateLogFilterBuildStep#setupLogFilters.

Relates to https://hibernate.atlassian.net/browse/HHH-17269