sql 2022-12-24 | Slack Archive

Using jdbc.next and seeing this error:

; Execution error (IllegalArgumentException) at java.util.GregorianCalendar/computeTime (GregorianCalendar.java:2790).
; HOUR_OF_DAY: 2 -> 3
clj꞉creditkarma.graphdb꞉> 
com.mysql.cj.jdbc.exceptions.SQLError/createSQLException (SQLError.java:129)
com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping/translateException (SQLExceptionsMapping.java:85)
com.mysql.cj.jdbc.result.ResultSetImpl/getTimestamp (ResultSetImpl.java:947)
com.mysql.cj.jdbc.result.ResultSetImpl/getObject (ResultSetImpl.java:1279)
next.jdbc.result-set.MapResultSetBuilder/with_column (result_set.clj:208)
next.jdbc.result-set/row-builder (result_set.clj:440)
...

This isn't a jdbc.next problem, rather something to do with converting a TIMESTAMP value and daylight savings time, but I'm hoping someone knows how to work around it using jdbc.next. Thanks.

sparkofreason14:12:10

Using plan instead of execute! on this query made this problem go away, which I don't understand, but I guess my problem is solved.

kulminaator08:12:25

i read through the underlying gregorian calendar compute time method and i'm happy to let you know that it looks horrible 😄

kulminaator08:12:00

your java version looks to differ a little bit (line numbers a bit off), but by the look of the exception this block blowing up is the same http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/util/GregorianCalendar.java#l2825

kulminaator08:12:29

if you can grab a hold with your debugger of what is going on there, it would be interesting to know .... right now this massive mutability array code there is not what i want to read 😄 my blind guess though -> there is the "empty hour" in dst switch (when the clock is turned from 2 to 3) that can not have anything in it .... any chance that your code tries to put something there?

kulminaator08:12:18

just in general - i would advise anyone to store whatever dates they need in utc, if at all possible. if users prefer to watch the output in some specific timezone then that can be done at interpretation level or even ui level. it is so much easier to handle utc than anything else 🙂

kulminaator08:12:35

if you can reproduce it in a test in your IDE and grab a hold of the gregorian calendar instance during the exception - would be helpful to know what you have managed to create 🙂

sparkofreason16:12:11

Thanks. I'll try to return to it once I muddle through this migration. I am curious why switching from execute! to plan made any difference, more than a little spooky.

seancorfield18:12:48

@U066LQXPZ when you reduce over plan, only columns you explicitly request are fetched from the underlying ResultSet object and no result set builder is involved; when you use execute!, all columns are fetched and run through the result set builder.

sparkofreason18:12:59

@U04V70XH6 I am explicitly fetching the (or at least a) date with plan. I'll double-check and see if there's maybe something weird with a date column and/or it isn't being explicitly processed via plan.

seancorfield19:12:41

Hmm, the only difference then should be that execute! will cause get-by-column-index (i.e., (.getObject rs i)) and plan will cause get-by-column-label (i.e., (.getObject rs label) -- access via string name of column in the query). So there may be an internal difference between those in the MySQL JDBC driver in terms of how data transformation is handled...

2022-12-24

Channels