Bug #106648 | ResultSet::getDate creates unnecessary stack trace | ||
---|---|---|---|
Submitted: | 6 Mar 2022 8:20 | Modified: | 9 Mar 2022 9:52 |
Reporter: | Jürgen Lind | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | Connector / J | Severity: | S4 (Feature request) |
Version: | OS: | Any | |
Assigned to: | CPU Architecture: | Any |
[6 Mar 2022 8:20]
Jürgen Lind
[6 Mar 2022 8:21]
Jürgen Lind
Changed title to better reflect the problem area
[7 Mar 2022 10:53]
MySQL Verification Team
Hi, What warning do you get? thanks
[7 Mar 2022 13:00]
Jürgen Lind
The warning generated is a ResultSet.PrecisionLostWarning. For me the problem seems to be the fact, that the ResultSetImpl registers iteself as the WarningListener of the SqlDateValueFactory. This triggers the call of the warningEncountered Method of the ResultSet which creates the stackTrace via the super() calls.
[7 Mar 2022 13:16]
MySQL Verification Team
Hi, Weird that getDate produces this warning. Anyhow, I have issues reproducing this, what kind of connection string is your spring app using? Are you using prepared statements (server or client side?)? If you maybe have a minimal test case I can play with as the quick test I whipped up did not reproduce this Thanks
[7 Mar 2022 13:31]
Jürgen Lind
The testcase where I have encountered the issue is actually quite simple - in the database, I have a column of type datetime(6) - I do not use any spring-stuff to get the connection, I'm using the DriverManager directly - The connection string has no parameters whatsoever - The method to extract the value from the ResultSet is getDate(String) If I switch to using getTimestamp, the performance is much, much better.
[9 Mar 2022 9:52]
MySQL Verification Team
Thanks
[19 Oct 2023 11:24]
Filipe Silva
Hi, This is not a bug. Connector/J rightfully creates this kind of warnings and at that time it must create an instance of java.sql.SQLWarning, which is an java.lang.Exception so it automatically collects the stack trace of the running thread. This is also not related to logging because you can get the warnings at any time, with or without logging enabled. The only alternative I see would be to implement an option that skips producing warnings altogether, but that would be a non-JDBC compliant vendor extension. So, this makes this report a feature request instead of a bug - changing the severity to S4 (Feature request). Thanks