Re: [hibernate-dev] JDBC warnings performance matter

+1 to allow a setting to control *logging* of SQLWarnings. I find it silly that MySQL handle it this way (I can only find reference to MySQL when I google search for `JDBC getSQLWarnings performance`) in terms of it being such a performance hit. However I really do not like the idea of fencing

Re: [hibernate-dev] JDBC warnings performance matter

I agree with providing a specific property to enable this behaviour. I noticed also that handleAndClearWarnings(Connection connection,WarningHandler handler) does the walking without checking for the log level. On 28 January 2016 at 07:59, Gunnar Morling wrote: > Is

[hibernate-dev] JDBC warnings performance matter

Hi, The guys at Plumbr wrote an article about how MySQL JDBC warnings are handled by Hibernate: https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate I remember seeing this issue on StackOverflow too and I was curious if you want to tweak it a little bit. I also

Re: [hibernate-dev] JDBC warnings performance matter

Is the call also expensive if there are no SQL warnings (i.e. null is returned, so no further walking is required)? It'd be my hope that drivers should be able to fetch the first warning - if any - upon statement execution without further round-trips. So getWarnings() would be cheap if no

Re: [hibernate-dev] JDBC warnings performance matter

If that’s effectively widespread, I think indeed we should guard this feature with an explicit property. It’s not necessarily easy to anticipate such consequences when designing things. In insight, something more explicit looks better. > On 28 Jan 2016, at 06:25, Vlad Mihalcea