Hi Martin, Thank you for your response to my questions.
On Tuesday, 6 May 2014 13:13:46 UTC+8, Martin Krasser wrote: Finally, I believe I would like to track all the events that get added to > the entire journal (treating it like a combined log). Is that possible? > Is it one big log-like thing or are there really separate journals for > each Processor? > > > Each processor has its own logical journal, although journal plugins > maintain them in a single physical backend store (replicated or not). This > is not a requirement but all plugins follow this pattern so far. So, from a > physical viewpoint there's a single big message store but this doesn't mean > that there is a global ordering of messages. An ordering of messages is > only defined within a processor (i.e. logical journal). Messages from > different processors are seen as unrelated by akka-persistence. > This is an interesting twist (IMHO), with regards to Eventsourcing with Akka Persistence. I was under the (perhaps naive) impression that in ES there would logically be some sort of event log that kept all events and that components could subscribe to such events. AP seems to be taking a different tack with per processor logical journals that are polled (in some sense, please correct me if I am wrong). I guess the proposed change / ticket will at least allow a View to follow all events. Similarly, what about a View that tracked changes to all Orders and all > Receipts? > > My understanding is that the Views will be used to update the read model > (e.g. some denormalised store, like MongoDB optimised for client > querying). > > > Yes, views are there to maintain read models. They may also keep state in > memory (and take snapshots) since it can be recovered by replaying messages > (optionally starting from a snapshot). > Good so I am on the write track. I am confused a little about the Views keeping stage in memory and with snapshots. What state would this be? Surely the read model itself is maintaining most of the state, e.g. in a database. Could the Views themselves sometimes be the read model that were queried by the client? Is that meant to be the primary approach or not? Views that track updates from many processors make absolutely sense and > have already been requested several times (see ticket). > Ok, this is good, I just thought perhaps I was not understanding the design of Akka Persistence and the way it should be used for CQRS/ES, for example. I have read the discussions and thanks for pointing out the ticket. I won't ask when we can hope for a solution but I will ask (not necessarily you but anyone reading) what are people doing until then? Thanks again for answering my newbie questions. I am really impressed with the elegance and simplicity of Akka Persistence and it's CQRS/ES components. Cheers, Ashley. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
