Fork me on GitHub
#clara
<
2017-08-23
>
ryanbrush13:08:42

@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 http://www.clara-rules.org/apidocs/0.15.2/clojure/clara.rules.html#var-mk-session

ryanbrush13:08:30

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.

ryanbrush13:08:58

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.

ryanbrush13:08:21

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.

souenzzo14:08:19

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

souenzzo14:08:42

I will try to move defrecord to another ns

souenzzo14:08:58

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)

souenzzo14:08:27

fixed. @ryanbrush clara docs should contains this info.

mikerod19:08:37

@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.

mikerod19:08:40

Not to suggest to use this lib or not, just to point out I’ve seen the same concern addressed before https://github.com/ztellman/potemkin/blob/0.4.4/src/potemkin/types.clj#L326

mikerod19:08:59

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

mikerod19:08:59

(still exists in schema now, but as an “optional” dependency https://github.com/plumatic/schema/blob/schema-1.1.6/src/clj/schema/potemkin.clj)

mikerod19:08:33

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

mikerod19:08:58

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

mikerod19:08:10

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

souenzzo19:08:21

There is a document about repl development https://github.com/cerner/clara-rules/wiki/Using-Clara-from-the-REPL just add a mention/reference/tip about "be warning on reload types/records across namespaces".

dadair20:08:44

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.one 'ns.shared) and (mk-session ['ns.one 'ns.shared]) and get a query invalid or not in rule base error for the shared queries

souenzzo20:08:46

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

dadair20:08:19

seams to be working now 😕 shrug

dadair20:08:29

must have had some weird REPL state