This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-23
Channels
- # beginners (55)
- # boot (37)
- # braid-chat (1)
- # chestnut (3)
- # cider (4)
- # clara (22)
- # cljs-dev (54)
- # cljsrn (3)
- # clojure (114)
- # clojure-italy (12)
- # clojure-losangeles (3)
- # clojure-portugal (1)
- # clojure-russia (1)
- # clojure-spec (30)
- # clojure-uk (67)
- # clojure-ukraine (1)
- # clojurescript (101)
- # core-async (11)
- # cursive (6)
- # data-science (27)
- # datomic (8)
- # figwheel (3)
- # fulcro (59)
- # graphql (2)
- # hoplon (89)
- # jobs (3)
- # jobs-rus (1)
- # leiningen (3)
- # lumo (19)
- # off-topic (9)
- # om (48)
- # pedestal (2)
- # portkey (4)
- # protorepl (19)
- # re-frame (13)
- # reagent (38)
- # remote-jobs (1)
- # ring-swagger (4)
- # spacemacs (10)
- # specter (2)
@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
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.
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 https://github.com/ztellman/potemkin/blob/0.4.4/src/potemkin/types.clj#L326
At one point Plumatic (formerly prismatic) Schema actually defaulted to using potemkin
s 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 https://github.com/plumatic/schema/blob/schema-1.1.6/src/clj/schema/potemkin.clj)
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
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".
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