another good link, that makes it understandable.
it looks like a "one-to-one" port of existing drools rules is problematic. Drools has a way for you to veto a rule firing, it also can allow us to skip rule groups. It looks like the equivalent involves just ensuring proper behavior by writing appropriate when clauses. I do like how using a defrecord to predicate on is simple.
i suppose the "clara way" to control groups would be to modify the productions --- add predicate(s)
i'm getting infinite loops: (defrule has-email "allow rule" [User (= "<mailto:wravel@mail.com|wravel@mail.com>" email)] [:not [Decision (contains? #{:allow} type)]] => (insert! (->Decision :allow)) (println "allowed")) (defrule has-email-deny "deny if not allowed" [:not [Decision (contains? #{:allow :deny} type)]] => (insert! (->Decision :deny)) (println "denied")) trying to make "allow" take precedence over "deny" decisions, but either my "contains" or universal non-existence seems to not be working.
@joel380 Does your Decision record have a "type" field? Perhaps you're running into https://github.com/cerner/clara-rules/issues/259
If that is the problem you can fix it by using an explicit field lookup e.g. (:type this)
(defrecord Decision [type])
I tried this format, didn't help: [:not [Decision (contains? #{:allow} (:type this))]]
kind of feel like i can't do "non-existance"
i see examples of the same ... i don't get what I'm doing wrong.
It actually works as expected if I add the fact when making the session.
changing salience fixes this!?
Regarding looking at fired rules, the idiomatic way to get output from the session would usually be to have facts that represent that output and query on those facts. The tracing listener will tell you what rules fired, but it will also include rules that were later retracted. The API guarantees are generally around the final state of the session, not what rules are fired on the way there. It's possible to design rules in a way that constrains this, but this has to be done carefully and wouldn't be my first approach to solving a given problem. The tracing listener is primarily intended for debugging and performance problem diagnosis.