I'm curious about the design decision of :onyx/params. Why a vector of keys that are then found in the catalog entry, and not a vector of values or keys and values interleaved?

@yonatanel: I think the overall idea is that task maps are primarily manipulated by adding and removing keys, merging, etc, and all of the onyx tooling reflects that. A vector of keys allows the fn to access anything added to the task map using these methods

For example, could have a base task map, that is meant to be used by users, that just has the param names, and those are to be added by the user by associng

I see. Thanks.

Thanks, team. I started with a clean slate and this time just ran docker-compse up rather then the docker-compse run … “start-peers”. That seemed to do the trick.

Good to hear. Probably some old compiled state somewhere

If I'm doing stateful computations on each peer, it's my responsibility to implement snapshotting that state if I don't want to read all segments from the beginning if something fails, correct? Or is there something already implemented or some known pattern in Onyx for that?

@yonatanel: if you use onyx's windowed aggregations, it will journal the state to bookkeeper and automatically recover it when peers fail

I like how as I read, all these questions about whether it will work for my scenario keep having positive answers :)

🙂

I'm doing learn-onyx/challenge-4-2 and I can't understand what the lifecycle event parameter represents, and how values set on it on before-task-start are later available in after-batch, and if state can be passed that way, why the need for defing it and not just create it in before-task-start.

The state can be injected in before-task-start but it would make it difficult to check afterwards in the test

@yonatanel Docs for the definition of every event parameter name: https://github.com/onyx-platform/onyx/blob/0.9.x/src/onyx/information_model.cljc#L515

I see, so its "lifetime" is the entire task. Thanks.

Yeah. Think of the lifecycle as a simple data machine that proceeds from A->B->C->D, and eventually D->A, where the letters represent discrete actions to perform with task data.