This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-20
Channels
- # announcements (1)
- # babashka (74)
- # beginners (84)
- # bristol-clojurians (3)
- # cider (2)
- # clara (14)
- # cljdoc (18)
- # cljsrn (7)
- # clojure (29)
- # clojure-australia (4)
- # clojure-europe (34)
- # clojure-italy (3)
- # clojure-nl (5)
- # clojure-seattle (1)
- # clojure-uk (33)
- # clojuredesign-podcast (2)
- # clojurescript (33)
- # code-reviews (17)
- # core-async (10)
- # cursive (8)
- # datomic (21)
- # depstar (45)
- # dirac (4)
- # duct (10)
- # emacs (1)
- # fulcro (8)
- # jackdaw (2)
- # jobs (1)
- # kaocha (11)
- # leiningen (2)
- # off-topic (8)
- # pathom (35)
- # pedestal (3)
- # protorepl (13)
- # rdf (39)
- # re-frame (23)
- # reagent (2)
- # releases (1)
- # remote-jobs (6)
- # reveal (2)
- # rewrite-clj (18)
- # shadow-cljs (51)
- # sim-testing (2)
- # spacemacs (2)
- # tools-deps (37)
what a good approach to ensure that a fact is only inserted once, kind of like a primary key in a DB?
I could have a rule where the RHS literally checks in a DB to see if the key is there, but it seems better to keep as much state as possible in the session?
At my team a couple of product specialists use Excel for logic like that and I was wondering if I can somehow turn them into Clara rules and use it to make decisions. Has anyone have done something similar in the past?
this aggregation rule is you explicitly choosing how you want to represent or handle multiple supporting matches
it’s not always obvious actually - if they happen to have different data associated with them them or something
@nikola.kasev I haven’t attempted anything first-class with tables like that - but you could start by just trying to make rule to represent it and see what patterns may emerge