Fork me on GitHub
Oliver George10:08:16

I'm interested in how Clara (or rule engines more generally) would work in an environment where a relational database is used as the repository of all information.

Oliver George10:08:32

I'm only learning about this stuff so I could be missing something obvious.

Oliver George10:08:35

Perhaps the key is not letting anyone directly write to the database which would bypassing the rule engine causing it to get out of sync with reality.

Oliver George10:08:15

A simple "typical architecture" might answer my question.


Can anyone explain why the following case doesn't do what I expect?


(let [matched    (dsl/parse-rule
                     (= ?attribute (:attribute this))
                     (= ?attribute_value (:attribute_value this))
                     (= ?id (:id this))]]
                   (insert! {:type ?attribute :id ?id :value ?attribute_value}))

      unscreened (dsl/parse-rule
                     (= (:value this) 2)
                     (= ?id (:id this))]
                     (= (:value this) -1)
                     (= ?id (:id this))]]
                   (insert! {:type :unscreened :id ?id}))

      type-query (dsl/parse-query [] [[?unscreened <- :unscreened]])

      session    (mk-session [matched unscreened type-query] :fact-type-fn :type :cache false)]
  (time (-> session
            (insert {:type :eav :attribute :state :attribute_value 2 :id 33695360})
            (insert {:type :eav :attribute :milestone :attribute_value -1 :id 33695360})
            (insert {:type :eav :attribute :milestone :attribute_value 123456 :id 33695360})
            (query type-query))))


I insert two facts which cause a third fact of type :unscreened to be inserted


I then fire the rules, and insert another fact which should negate the earlier fact


Instead, when I query the session for :unscreened, I see that fact still present