This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-01
Channels
- # beginners (121)
- # boot (12)
- # cider (14)
- # clara (19)
- # cljsjs (1)
- # clojure (124)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-russia (47)
- # clojure-spec (20)
- # clojure-uk (7)
- # clojurescript (102)
- # cursive (16)
- # datomic (10)
- # emacs (2)
- # events (2)
- # immutant (3)
- # luminus (5)
- # lumo (33)
- # off-topic (2)
- # om (5)
- # onyx (22)
- # parinfer (1)
- # pedestal (32)
- # protorepl (1)
- # re-frame (6)
- # reagent (2)
- # ring-swagger (2)
- # rum (1)
- # spacemacs (8)
- # specter (17)
- # yada (1)
when storing aggregates to an outside store (say, redis), are there any tools onyx provides to ensure idempotence for this ?
for example, i’m keeping track of an ever-increasing counter, and my trigger is set to discarding — what would be the best way to ensure consistency (assuming the data store is able to do transactions) ?
i probably need to implement some additional mechanism on top of onyx to achieve this, eh ? or does onyx provide some tricks internally to achieve this (e.g. inspecting any of the maps that are provided to the trigger/emit
/ trigger/sync
functions)
i’m probably approaching this at the wrong angle, though… another approach might be CQRS-like snapshotting and onyx resume points 🙂
ah, i think i’ve figured this out mentally by now — i think i should treat the last event id as the ‘version’ of the aggregate, and use that as a way to achieve consistency — if i ever need to rebuild the aggregates, i can seek towards that event id
my thinking problem was that i was treating the aggregates as a source of truth, while in fact they are a proxy of the truth
@lmergen Nice conclusion. 🙂
Onyx can’t do much for you at the edges when you start talking to external storage provides as far as idemotency goes. Some design work is needed there - you’re on the right path. 😄
He writes quality material.
or rather, i might want to use some data of ABS to use the same barrier/epoch for my aggregate versions
@anujsays Case-2 would attempt to put a function in an Onyx job. Jobs are strictly data.
We do it for concision, at any rate. Most real use cases of lifecycles have chains of calls that are a bit pointless to respecify every time.
Ok, I understand now. Thanks @michaeldrogalis
@lmergen If you write an output plugin you can actually be told the current replica version and barrier epoch
and when it needs to recover, it’ll restore to a particular replica version and epoch, so you can determine whether any data is out of date at that point
https://github.com/onyx-platform/onyx/blob/0.10.x/src/onyx/plugin/protocols.clj#L11
We just landed a patch in master that extends the public API to optionally receive a persistent Onyx client, rather than resconstructing one from scratch on each call: https://github.com/onyx-platform/onyx/pull/764
This enables rapid, successive calls to submit-job
, kill-job
, etc.