Fork me on GitHub

@souenzzo There are a couple pitfalls on the that can happen. One is that the rule session is being cached, so you're re-running previous rules. This can be turned off by passing :cache false to mk-session as described at


The other pitfall that can happen is if you're reloading your fact types, the reloaded types may be a different class than what Clara was compiled against, so the facts won't match.


This can also be addressed by not caching the rules session as described above, or by placing the fact types in a namespace that isn't reloaded in your REPL.


Of course, this only applies if you're using the Java or Clojure type system for your facts (which is the default) rather than using a custom fact type.


Already tryied with :cache false, :cache true...


I will try to move defrecord to another ns


Oh. I noticed that my problems started when I started importing records in different namespaces. (still moving to test if records in a "standalone" ns will solve)


fixed. @ryanbrush clara docs should contains this info.


@souenzzo Just to add to this conversation: This does sound like something that may be a good idea to point out in some sort of Clara docs, especially concerning development time. However, records getting redefined I think is often at odds with a dynamic repl reloading workflow. I don’t think Clara is the only place affected.


Not to suggest to use this lib or not, just to point out I’ve seen the same concern addressed before


At one point Plumatic (formerly prismatic) Schema actually defaulted to using potemkins defrecord+ to avoid recreated classes with the same name, that have no impl change, in a new dynamic classloader during (probably repl) reloads


(still exists in schema now, but as an “optional” dependency


I’m just pointing this out because in the past I used this “non reloading” style of defrecord to avoid weird issues with a record class getting reloading, with references still around to the old version of the class


you can get away with moving record definitions into some namespace you are careful to not :reload though


as long as you don’t want to do something like :reload-all


There is a document about repl development just add a mention/reference/tip about "be warning on reload types/records across namespaces".


Is it possible to specify multiple namespaces for mk-session? I have rules organized across a couple namespaces (to guarantee zero collaboration between two distinct rule sets that use common facts), and want to share common queries in a shared namespace. I've tried both (mk-session ' 'ns.shared) and (mk-session [' 'ns.shared]) and get a query invalid or not in rule base error for the shared queries


(mk-session ' 'full-ns.name2) works for me


seams to be working now 😕 shrug


must have had some weird REPL state