This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (25)
- # asami (39)
- # beginners (39)
- # biff (12)
- # clojure (53)
- # clojure-dev (4)
- # clojure-europe (6)
- # clojure-hungary (1)
- # clojure-norway (4)
- # clojure-spec (3)
- # conjure (2)
- # cursive (1)
- # dev-tooling (9)
- # emacs (4)
- # introduce-yourself (2)
- # juxt (4)
- # membrane (8)
- # off-topic (3)
- # polylith (8)
- # portal (4)
- # releases (1)
- # scittle (9)
- # sql (11)
- # squint (5)
- # xtdb (12)
jdbc.next and seeing this error:
This isn't a
; 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) ...
jdbc.nextproblem, rather something to do with converting a
TIMESTAMPvalue and daylight savings time, but I'm hoping someone knows how to work around it 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.
i read through the underlying gregorian calendar compute time method and i'm happy to let you know that it looks horrible 😄
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
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?
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 🙂
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 🙂
Thanks. I'll try to return to it once I muddle through this migration. I am curious why switching from
plan made any difference, more than a little spooky.
@U066LQXPZ when you
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.
@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
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...