Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
Hibernate Show SQL
I work with 7.3.2 GA
Can anyone confirm that the setting
It's still in the portal.properties, but if I search the portal sources for it, then it looks like it is not used anywhere...
I don't get any additional output in the logs.
And, if it's not working any more, what's an alternative way to get insights into the generated SQL? Change some logging properties...?
Can anyone confirm that the setting
hibernate.show_sql=true
is not working anymore?It's still in the portal.properties, but if I search the portal sources for it, then it looks like it is not used anywhere...
I don't get any additional output in the logs.
And, if it's not working any more, what's an alternative way to get insights into the generated SQL? Change some logging properties...?
Hi Andre,
The property hibernate.show_sql=true is read by hibernate library itself, so you are not going to see any reference to that setting in Liferay code.
For more information see "hibernate.show_sql" in hibernate documentation: https://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/session-configuration.html
I think it should work because Liferay hasn't change the hibernate library version for a long time ago.
Instead of using hibernate.show_sql=true, you can also try configuring from control panel following log4j category to TRACE level:
If you want to change the show_sql setting, you have to shutdown the application server.
If that doesn't work, you can also try getting SQL queries from JDBC driver or from the database level.
At JDBC driver level, you can use P6Spy library. That library intercepts all SQLs that are sent to database and they are written to log file.
For more information about P6Spy, see:
Regards,
Jorge
The property hibernate.show_sql=true is read by hibernate library itself, so you are not going to see any reference to that setting in Liferay code.
For more information see "hibernate.show_sql" in hibernate documentation: https://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/session-configuration.html
I think it should work because Liferay hasn't change the hibernate library version for a long time ago.
Instead of using hibernate.show_sql=true, you can also try configuring from control panel following log4j category to TRACE level:
- org.hibernate.SQL
- org.hibernate.type
If you want to change the show_sql setting, you have to shutdown the application server.
If that doesn't work, you can also try getting SQL queries from JDBC driver or from the database level.
At JDBC driver level, you can use P6Spy library. That library intercepts all SQLs that are sent to database and they are written to log file.
For more information about P6Spy, see:
- https://github.com/p6spy/p6spy
- https://liferay.dev/blogs/-/blogs/integerate-p6spy-with-liferay-to-format-hibernate-sql
- https://liferay.dev/blogs/-/blogs/debugging-sql-queries-with-p6spy
Regards,
Jorge
Thanks!
That helped :-)
In 7.3.2 there's only one log level to change: org.hibernate. And yes, it shows the SQL in the log but unfortunatly without the parameters that are added to a native SQLQuery (CustomSQL). They are still shown as "?".
But at least I can see that Hibernate does the binding of the parameters and then, if no error occurs, I can suppose that the correct SQL was created.
Maybe i'll have a look at the p6spy way later...
Anyway, thans for answering.
That helped :-)
In 7.3.2 there's only one log level to change: org.hibernate. And yes, it shows the SQL in the log but unfortunatly without the parameters that are added to a native SQLQuery (CustomSQL). They are still shown as "?".
But at least I can see that Hibernate does the binding of the parameters and then, if no error occurs, I can suppose that the correct SQL was created.
Maybe i'll have a look at the p6spy way later...
Anyway, thans for answering.