This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-14
Channels
- # babashka (53)
- # beginners (158)
- # calva (25)
- # cider (21)
- # clara (1)
- # clj-kondo (12)
- # cljsrn (6)
- # clojure (94)
- # clojure-australia (2)
- # clojure-bay-area (6)
- # clojure-europe (40)
- # clojure-nl (10)
- # clojure-spec (16)
- # clojure-uk (18)
- # clojurescript (95)
- # cursive (14)
- # data-science (1)
- # datascript (6)
- # datomic (18)
- # depstar (2)
- # duct (36)
- # emacs (15)
- # events (4)
- # fulcro (16)
- # graalvm (10)
- # helix (25)
- # honeysql (6)
- # jackdaw (4)
- # jobs (2)
- # leiningen (24)
- # lsp (4)
- # malli (10)
- # off-topic (3)
- # pathom (3)
- # polylith (19)
- # practicalli (4)
- # prelude (1)
- # re-frame (6)
- # reagent (13)
- # reitit (3)
- # remote-jobs (10)
- # ring (12)
- # ring-swagger (2)
- # shadow-cljs (54)
- # testing (17)
- # tools-deps (10)
- # xtdb (14)
Hi again, long time no speak 😄
Thank you for the blog post about (bi)temporality being very important nowadays...I think I really see this in my current (new) workplace (healthcare).
One of the things we have as a requirement is a list of every "business events" that happened to an entity/record.
Event sourcing is the obvious choice we have but I was trying to understand how I would satisfy that use case with crux
instead...
One idea I remember maybe have seen here was to have a custom transaction function enabled on some entity that "tags" the update with the, say, event type...
Hey, congrats on the new role! 🙂 There's quite a few ways to apply Crux to an event sourcing design but I'm not sure there's an obvious "best" option. It certainly depends a lot on the scale of the system, like: • how many projections you expect to model in the same Crux instance, and • the average/maximum expected length of the event sequence • whether you need "point-in-time" temporal queries, easy access to old projection states, or can live with rebuilding inactive projections on demand
not yet but to reduce the scope I was thinking of POC-ing exposing the "business centric" logs of a record
it does not have to be "reactive" - I would just query it ad-hoc but it would be nice to have something that gives me both attributes and the events from a certain date...I am certain this is doable in crux but I have to find the most elegant solution in order to motivate the move 😄
if instead I wanted to go for tagging transactions then I could instead probably show off the queries with valid-time
- which would definitely make crux
shine
Did you consider attaching the business event to the affected entities as a referenced entities? I.e. storing the business event and updating the events with a reference to the former? FatimidDatomic supports metadata on transactions, no sure about crux.
I'm guessing Fatimid was an autocorrect for Datomic 😄 there's no reified transaction log in Crux, but you can maintain your own metadata log entity that references the changed entities, and in general use the entity-history
API to efficiently correlate histories when needed
Uhm ok thanks to both I will have to try that
The only thing there then is that I still don't see from what I have read about the blog post is how crux
would be a (simpler) alternative to event sourcing...again I might have been missing some nuance that POC-ing will unveil 🙂
@U899JBRPF oh the perils of mobile phone typing. I’ve corrected the sentence.
@U0C8489U6 there would also be the option to store the event stream to crux and also store the reified data as processed from the even stream into crux as the read model. separately. This can be even done with tx-functions I suppose.