Hi Jeroen, On Friday, 27 June 2014 05:13:54 UTC+8, Jeroen Gordijn wrote:
Why do you need a view that watches multiple Processors? This can already > be achieved. You create a child View for every Processor you would like to > watch. The child simply forwards all messages to its parent. > There are two (or three) reasons I would suggest, please correct me if I am wrong: 1. What if there are a very very large number of Processors (e.g. for each Customer aggregate root) Do we keep the Views for each Processor (as there could be more than one) active all the time? If they are not active then (AFAIK) they will not be updated and when a query comes in for that View they will need to be activated and recover their state. A View that could be notified of changes to any Processor of a specific type could create/activate and update that Processor's View as needed so that it is ready for a subsequent query. This could include putting the view into an external store. 2. What if the Processors have a one to many association with another type of Processor (e.g. each Customer can have many Songs) One of the roles of the read side in CQRS is to enable (possibly multiple) denormalised read models. How do we maintain DenormalisedView of Processor (e.g. Customer with Songs) without having all the Views of the associated Processor also active? A DenormalisedView(s) that could be notified of changes to one of its dependent Processors could create/activate that Processor's View and update the denormalised view(s) based on that. 3. When both (1.) and (2.) above occur (which I think is quite common). If you can think of a way to efficiently do these at scale I would be very interested to hear. From my understanding of CQRS it is common for the read side to be able to subscribe to notification of changes to the event store so as to efficiently handle the cases above. Akka Persistence's current approach (as far as I can tell and confirmed somewhat by Patrik) can't really handle the cases above efficiently or at scale because of this lack of more general notifications (i.e. it just updates active Views at regular intervals based solely on one specified Processor). Patrik in another thread suggested implementing the above scenarios using notifications with an external distributed pub-sub and Pawel has done just that in his fantastic DDD-Leaven-Akka examples using Apache Camel and ActiveMQ (but there are still limitations, e.g. rebuilding denormalised views). It's a shame that Akka Persistence doesn't seem (on its own) fully functional for CQRS as yet (IMHO). It is still experimental, of course, so there is great hope that something will be done to address this. 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.
