clara

http://www.clara-rules.org/
Joel 2019-04-24T02:05:36.019900Z

another good link, that makes it understandable.

Joel 2019-04-24T02:09:13.022100Z

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.

Joel 2019-04-24T02:41:28.023Z

i suppose the "clara way" to control groups would be to modify the productions --- add predicate(s)

👍 1
Joel 2019-04-24T04:36:47.024500Z

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.

2019-04-24T08:33:44.024600Z

@joel380 Does your Decision record have a "type" field? Perhaps you're running into https://github.com/cerner/clara-rules/issues/259

2019-04-24T08:34:45.024900Z

If that is the problem you can fix it by using an explicit field lookup e.g. (:type this)

Joel 2019-04-25T01:51:23.000300Z

(defrecord Decision [type])

Joel 2019-04-25T01:58:08.000500Z

I tried this format, didn't help: [:not [Decision (contains? #{:allow} (:type this))]]

Joel 2019-04-25T01:59:00.000700Z

kind of feel like i can't do "non-existance"

Joel 2019-04-25T04:01:29.000900Z

i see examples of the same ... i don't get what I'm doing wrong.

Joel 2019-04-25T04:09:53.001100Z

It actually works as expected if I add the fact when making the session.

Joel 2019-04-25T04:45:19.001300Z

changing salience fixes this!?

2019-04-24T08:44:02.034Z

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.