11:25 p.m.
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
1:46 a.m.
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> 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
1:59 a.m.
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>:
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> 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
6:13 a.m.
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> 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>:
> 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>
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
7 a.m.
+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 <dreborier(a)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 <gunnar(a)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 <emmanuel(a)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.vlad(a)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-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
3211
days inactive
3211
days old
4 comments
5 participants
participants (5)
-
andrea boriero -
Emmanuel Bernard -
Gunnar Morling -
Steve Ebersole -
Vlad Mihalcea