Clojurians Log v2

Hi @seancorfield! Is it possible that the effect of extend-protocol next.jdbc.result-set/ReadableColumn somehow "randomly" depends on the order of loading things? I sometimes observe that it seems not to have taken effect and I suspect it it because this is inside a library my app depends on while the app also depends on next.jdbc directly. Could it happend based on through which of the two "paths" next.jdbc is loaded first? The library has the extend-protocol call at the very top, extending ReadableColumn to java.sql.Timestamp to convert it into java.time.Instant . Further down in the same namespace I have a function that reads a timestamp from the DB and tries to use it as an Instant and fails in some instances of the REPL because it gets java.sql.Timestamp instead. This never happens in prod, only when running the app locally, from a REPL. Any tips? 🙏

@holyjak If the protocol itself gets reloaded and your extend calls don't, that could be the cause

it would essentially be the same as

(deftype A [])

(defprotocol B 
  (f [_]))

(extend-protocol B
  A
  (f [_] "abc"))

(defprotocol B 
  (f [_]))

so the var f would be rebound to the new protocol function

and would throw if called on A

Hm, that could be related, thank you! I think we did (clojure.tools.namespace.repl/refresh) Though I would expect it to reload both things and in the correct order ... /cc @haakon

Solution: don't use tnr/refresh 🙂

(this is exactly why I avoid these reload/refresh workflows!)