Persist vs emit

[johanandren]

In Akka Persistence the effect is persist(event), can we align that instead of calling it emit(event) here to keep it familiar?

[huntc]

Patrik's initial spec was around emitting an event, and technically that's all it does. Whether it persists of not is up to the handler.

[patriknw]

In Akka EventSourcedBehavior we name it persist. In Kalix it is emit. I think it's more important to align with Akka here. Sorry if I said anything else previously.

[huntc]

No worries. We can easily rename it. Although I'm still concerned that emitting an event doesn't have to persist. Which I guess is the same in Akka too...?

[johanandren]

I think we'll always expect the emit/persist effect to signal the intent to store the event(s) somewhere.

[huntc]

I think we'll always expect the emit/persist effect to signal the intent to store the event(s) somewhere.

This is worth more of a discussion. One of my apps presently emits events that are not destined for being persisting i.e. the events are ephemeral.

[johanandren]

Why are the event going via the streambed log in such a use case and not only through some async channels?

I think that in the case of an Akka RS Event Sourced entity, a user have already chosen to do event sourcing and would have expectations around how it works, handle command turn them into stored events etc. rather than that they can do anything imaginable using the API.

[huntc]

Does event sourcing always mean that events are persisted? I've not operated exclusively on that principle, but I could be wrong.