These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
EventsourcedActorand rely on the
EventsourcedWriterto reliably update the database from written events. The
EventsourcedActorshould maintain a write model that can be used for command validation.
UserCreated(userId, ...)events which add a row in a
Usertable of a query database, you can get uniqueness constraints violations when you are re-using
userIds, for example. In this case the application should ensure that
userIds are uniquely generated. Obtaining a unique
userIdshould be done during command validation. Furthermore, having the write model in-memory doesn't require all the DB content in memory. Here, you'd only need
userIds in memory or have them managed by an external
userIdgenerator which can even be the target database from which you could request new userIds.
EventsourcedActors in different locations using same eventlog? There could be a race while that change is propagated to other locations even if I check parent existence in command handler.
ConcurrentVersions[Vector[String], String]that can only append elements. But what if the state is more complicated data structure with nested maps, lists, etc that allows to add, remove, update parts of its structure? Looks like it would require versioned state of type
ConcurrentVersions[ComplicatedStateType, CommandType]so that is could be updated correctly depending on command type. Am I right?
VersionedAggregatepurpose described somewhere in docs?