-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how can I tell what database I'm connecting to? #40922
Comments
Hahaha, no, sorry, my bad. What actually happened is that fairly recently @Sanne changed a very useful message which has always been logged at I have never really noticed the change, because in my projects I have a standard log4j.properties file which sets:
which apparently is there precisely to undo the effect of that change. Now, usually when I'm developing Hibernate, I would not even care much about this particular log message because there are a couple of other messages coming from But Agroal is much less noisy, logging nothing at all. So I don't see:
And I don't even know what database I'm connected to. |
Maybe it's not related to this issue, but Quarkus seems to only be able to select the correct dialect only for supported databases. It would be nice if quarkus would let us know when it's using the default dialect version because the database is not supported, and mention the property |
You can certainly alter the extension to log a line looking something like:
And append something like this if db-version is not set explicitly:
That being said, people in this project have strong opinions about logs on startup and have been actively hunting them down. |
I see now that Quarkus cannot select on its own the correct dialect + version. |
I'm pretty sure the dialect is mandatory for unsupported databases. The version is always optional, and the reason is part upstream (ORM has default versions for all dialects anyway), part history (the concept of DB version only appeared in ORM 6) and part Quarkus "philosophy" ("thou shall not require any configuration for Quarkus to start"). To be clear, I also think it only makes sense to force people to explicitly select a DB version. I agree with you. We mandate it for Elasticsearch in Hibernate Search, by the way.
... so I don't see it happening anytime soon. Displaying the defaulted version on startup could be a nice first step; at least people would be able to notice there is something wrong in their config. |
Thanks for the clarification.
Yes, I think this would be really helpful |
Yes this is all reasonable. I would also log the product name of the database FWIW. |
+1 to improve the logged details and docs. I think the wording should focus on stating what's the "minimal database version we'll be compatible with" though, that should make it clearer to users that there's some usefulness in this. There's often a need to build an application which is compatible with a certain range of DB versions rather than what one is happening to connect to today, or developing with in their dev environment; if our users can see that they would understand that this inconvenience of needing to specify an additional property is actually a quite reasonable feature. |
So what we still need to establish is, exactly who is responsible for logging what: I would propose that we add But then:
|
Note this will prevent:
So even if Hibernate ORM does it, we might want to override what's done and do it again in Quarkus with more context.
It basically depends where you do it in the
Quarkus only hides very specific messages, so it's unlikely it will hide a new log. |
@yrodiere so it sounds like "both" is viable... |
Description [EDITED]
After a fairly recent change to log levels in Hibernate, I get no confirmation at all about what database Hibernate is connecting to without turning on
DEBUG
logging usingquarkus.log.category."org.hibernate".level=DEBUG
, which fills my log with hundreds of useless messages which I have to hunt through to find what I'm looking for.This results in a surprisingly poor experience at development time. It's really hard to see, for example, whether setting:
actually had any effect at all, or whether I'm still just connecting to h2.
Implementation ideas
No response
The text was updated successfully, but these errors were encountered: