Fork me on GitHub
Jakub Holý (HolyJak)16:12:37

Hello! Do you know whether can somehow destroy

(extend-protocol next.jdbc.result-set/ReadableColumn
  (read-column-by-label [^Timestamp x _] (.toInstant x))
  (read-column-by-index [^Timestamp x _2 _3] (.toInstant x)))
? Because I get sometimes class cast exception due to having java.sql.Timestamp instead of an Instant (i.e. the protocol extension not having the intended effect), from a fn inside the same namespace that also includes ☝️ at the very beginning. I believe this only happens during development so I suspect the ns refresh could be the cause because I can think of nothing else. Thank you!


It would run it again surely?

Jakub Holý (HolyJak)18:12:08

I would expect it but obviously something is wrong


@holyjak I see so many people running into weird stuff like this from reload/refresh workflows that I swore off using them years ago. They seem to work just fine in many cases until they just don't 😞

👍 3
😭 3

you shouldn't use the fully qualified name of the var holding the protocol


using the fully qualified var (usually) means you don't have the namespace the protocol is defined in required, which means depending on what tool you use for reloading that dependency is missing


which is why it breaks some times, next.jdbc.result-set gets reloaded, but the reloading tool doesn't know the namespace you have that extend-protocol in depends on that namespace, so doesn't reload it

Jakub Holý (HolyJak)19:12:52

Thank you, that is a very good point! Though I actually do have a require for [next.jdbc.result-set :as jdbc-rs] so the cause must be somewhere else...


then it is a similar issue farther up the chain, you have a namespace where that expects Timestamp to satisfy the next.jdbc.result-set/ReadableColumn protocol, but doesn't depend on the namespace where next.jdbc.result-set/ReadableColumn is extended to Timestamp