@zhangjiji
Nothing here yet.
Nothing here yet.
No blogs yet.
Regarding state reads, I imagine they happen in shardcake 's behavior. Then, the ZPure DSL is run, generating events. These events are sent to the DB. After successful DB operations, the in-memory state is updated using the same event handler lifted via lift . Is my description accurate? If STM is involved, it might be harder to conceptualize, as those cross-module events would also need to be atomically committed to the DB. Could you please advise if there are any good libraries for CockroachDB ? Pierre Ricadat
I did see akka-persistent-cockroachdb in devsister's GitHub repository, but I assume this was used before migrating away from Akka, correct? Is the actual event sourcing interaction still using Akka / Pekko, or is it implemented separately? Also, are there any recommended ZIO libraries for interacting with CockroachDB?
Hello, I saw in your "Beautiful Domain Logic" slide that you discussed Event Sourcing, and it seems like events are written to both a database and a message queue like Kafka. My questions are: Is Event Sourcing actually used in games? Does the database encounter performance issues due to the large number of event records? How is Event Sourcing integrated with sharding (like Shardcake)?
If ZPure is used together with Event Sourcing, because Event Sourcing has an EventHandler that folds events and applies them to the state, and ZPure also describes the change from the oldState to the newState, does this mean that the change function is provided by the State model and is called in both ZPure and the EventHandler? But is it still necessary to coordinate the changes in ZPure and the changes in Event Sourcing to be consistent?
I apologize, I'm still a bit confused about the Random part. I understand it's like defining something like: def nextInt: Program[Int] = ZPure.suspend(ZPure.attempt(rng.nextInt()))? Does using Scala's Random directly lead to a loss of purity? Could you please explain it a bit more concretely? Thank you.