+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 the *clearing* of SQLWarnings based on this setting. On Thu, Jan 28, 2016 at 6:14 AM andrea boriero <drebor...@gmail.com> wrote: > 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 <gun...@hibernate.org> 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 <emman...@hibernate.org>: > > > 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.v...@gmail.com> > > 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-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 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@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
