This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-27
Channels
- # aleph (1)
- # announcements (5)
- # babashka (13)
- # beginners (68)
- # brompton (7)
- # calva (10)
- # cider (1)
- # clara (15)
- # cljsrn (2)
- # clojure (63)
- # clojure-austin (1)
- # clojure-europe (44)
- # clojure-france (2)
- # clojure-nl (5)
- # clojure-norway (1)
- # clojure-poland (1)
- # clojure-uk (8)
- # clojurescript (8)
- # clojureverse-ops (7)
- # conjure (13)
- # core-async (27)
- # cryogen (10)
- # cursive (17)
- # datomic (13)
- # deps-new (1)
- # events (1)
- # fulcro (3)
- # gratitude (4)
- # helix (6)
- # honeysql (6)
- # introduce-yourself (1)
- # jobs (2)
- # malli (13)
- # meander (9)
- # music (1)
- # news-and-articles (2)
- # off-topic (8)
- # pedestal (1)
- # reitit (4)
- # sci (25)
- # shadow-cljs (13)
- # spacemacs (2)
- # tools-build (5)
- # tools-deps (20)
- # vscode (50)
- # xtdb (2)
I've used Clara rules a bit but am planning on doing something more complicated with it and had a question. It seems like when you start working on defining your rules you have to decide on a sort of scope for your session. I was curious if sessions have any way of composing? Let's say I decide I want to handle some subset of rules in its own session and then apply that to many of some type in a parent session. Is that possible?
I don't think that Clara has anything like that. I would assume that one could fire the sub session, then extract data via queries to populate facts within the parent session. Though I would think that simply having a single session would be less complex
Is there any general wisdom about what a session should operate on? Like let's say I had some domain for accounts, should my session be for a single account vs all accounts, which I imagine could get confusing because you're dealing with many things vs one?
In general, It would come down to the scope of what you are reasoning about. If all of the questions you are trying to answer, if all of them are bounded by a single account, then it would probably make sense to operate on a single rather than multi.
It would likely reduce the complexity of the rules, as they could implicitly assume that the facts pertain to a single accout
I think in my case it's most likely the scope will be both the single and the many, at least for some parts. Which is why I was worried starting at one level would require lots of rework later to adjust the scope.
Going from multi to single, in theory, should be passive. Though single to multi would require rework as the implicit assumptions based on a single account would be broken
Right, without the ability to compose sessions, starting at many is probably the way to go to avoid rework.