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 <mihalcea.vlad(a)gmail.com&gt; wrote: > > 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-wi... > > I remember seeing this issue on StackOverflow too and I was curious if you > want to tweak it a little bit. > I also agree that relying on the log levels to prevent fetching warnings > might come as a surprise to many users and we should document this behavior. > > We could also have a hibernate.jdbc.log.warnings boolean property to > control whether we want to log those warnings or not. > This way, if users set the logger level to WARN, they will see the logs > generated by the framework stack and the JDBC warnings will be logged only > if this configuration property is true. > > What do you think? > > Vlad > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 <gunnar(a)hibernate.org&gt; wrote: > 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 warnings exist. In that case people > should IMHO actually fix the warnings instead of complaining that > reporting them takes time. > > If it is a general perf issue also if no SQL warnings exist, +1 for > having a property for opting into logging them. > > 2016-01-28 8:46 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > > 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 <mihalcea.vlad(a)gmail.com&gt; > wrote: > >> > >> 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-wi... > >> > >> I remember seeing this issue on StackOverflow too and I was curious if > you > >> want to tweak it a little bit. > >> I also agree that relying on the log levels to prevent fetching warnings > >> might come as a surprise to many users and we should document this > behavior. > >> > >> We could also have a hibernate.jdbc.log.warnings boolean property to > >> control whether we want to log those warnings or not. > >> This way, if users set the logger level to WARN, they will see the logs > >> generated by the framework stack and the JDBC warnings will be logged > only > >> if this configuration property is true. > >> > >> What do you think? > >> > >> Vlad > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev