Hi,
We're using mount to handle a single connection to a datomic database in our app, and
recently ran into an issue.
To fully describe what's happening here:
we have two git branches (develop and feature/add-feature)
On develop, db.clj resides at src/datomic_to_catalyst/utils/db.clj (ns: datomic-to-catalyst.utils.db)
On the feature branch, we moved the db.clj module up a level.
Switching between the two branches and issueing any lein repl/run/ring command will cause re-compilation to be attempted, which triggers the error linked to above.
In order to work around the error, the following steps "work around" the issue:
switch git branch
run lein .... (ClassDefNotFound error is thrown pointing at mount/core/DeferrableState | defstate macro)
touch -m <path to db.clj>
run lein (works again)
Repeating steps 0 .. 3 (on a different branch where db.clj is re-located) re-produces the error consistently.
Investigating further, my colleague found that disabling aot compilation also works-around this issue.
I found this which seems to indicate that this could be the cause of the issue here.
Specifically, the following passage was an "ah-ha!" moment:
set-logger! is a macro that makes use of the ns var. ns contains the current namespace and, due to what I’m assuming to be special semantics regarding this particular var, it shouldn’t be unquoted within a macro - which is why it was failing in AOT mode.
(Our project.clj is currently using aot compilation)
Hi, We're using
mountto handle a single connection to a datomic database in our app, and recently ran into an issue. To fully describe what's happening here:developandfeature/add-feature)develop,db.cljresides atsrc/datomic_to_catalyst/utils/db.clj(ns:datomic-to-catalyst.utils.db)Switching between the two branches and issueing any lein repl/run/ring command will cause re-compilation to be attempted, which triggers the error linked to above. In order to work around the error, the following steps "work around" the issue:
<path to db.clj>Repeating steps 0 .. 3 (on a different branch where db.clj is re-located) re-produces the error consistently.
Investigating further, my colleague found that disabling aot compilation also works-around this issue.
I found this which seems to indicate that this could be the cause of the issue here.
Specifically, the following passage was an "ah-ha!" moment:
(Our project.clj is currently using aot compilation)