Calvin (8) [Avatar] Offline
Hello there,

I took a look at Chapter 8 hoping to find some material on building out the Query side (for complex queries across entities that cannot be answered by the command side) with respect to Akka Persistence and the usage of Akka Persistence Query for Event Sourcing + CQRS but I didn't find any material on this. I noticed you briefly mention read projections with the example of the Employee but there's no real concrete implementation examples. Is this done on the database side? or is there some application code that's doing this process? What happens if that application goes down?

Also I noticed that there's no mention of adding new read sides, how would this be done? I know Greg Young did a talk where he says that if you don't have a Consumer Driven subscription model, then it's very difficult to pull this off since if the read sides get corrupted and they need to be restored from scratch and there's no way to demand data from inception from the command side and also adding new read sides without this would be very difficult.

Is it recommended to use multiple Akka Persistence Queries with offsets to feed the different read sides? Would be okay to have the read sides keeping track of the offsets in case they went down and would use this as a starter point instead of starting from inception every time they went down?

Are you planning to add any material on Persistence Query and an example of how to write a Query model?

jjmargon (11) [Avatar] Offline
I completely agree with the comment below.

Just as simple consideration also, don't you think it's better to change the order of the C (Command) and Q(query) explanations of this chapter?

I mean, first, explain the C side. And then, explain the Q side based on projections of the propagation and publication of the events that changed the model state based on those commands.

As it's written now, you first read Q section, then C on, and then have to review Q side again once the C side is understood.