Thank you for your post Endre. On Friday, 20 June 2014 16:39:46 UTC+8, Akka Team wrote: > > Can you please give me a quick idea of how this could be implemented >> effectively now (i.e. a View with a known set of Processors to follow)? >> > > A View corresponds to one processorId but you can have for example an > aggregate actor that has two Views as children, receiving updates from both > (and supervising them) and doing aggregation. Of course you should be able > to collate messages coming from the two view to avoid inconsistencies. >
This sounds like it may be ok for one DenormalisedView with a few Views as children actors. However, there are some further constraints that I feel don't fit so well: 1. What happens when there are a very large number of DVs each based on hundreds of Vs? And what if different DVs have the same Vs? This seems like a lot of actor infrastructure just to create denomalised views, especially since an actor can only have one parent (AFAIK) so there would be many duplicate Vs. 2. You suggest the V actors would message their parent DV actor, so this suggests to me that all the Vs (and DVs) have to be active all the time polling for changes to their processor. With a very large number of DVs with hundreds of Vs each this seems an inefficient way to maintain denomalised views. Please correct me if I am misunderstanding something (which could be very likely). Of course, the read model is all about queries so perhaps we could drive it from the queries rather than the other way around. When a query comes for a DV (or V) we could construct the actor hierarchy (DV and Vs) to update the denormalised view but this would need to be done for every query. It seems to me the best (and the most common) way to effectively implement this is to have it event-based, so that a change in a processor signals an update to a view (cached somewhere) which then signals an update to a denormalised view(s) (cached somewhere). Queries can just read simply from an up-to-date view or denormalised view which could be stored in V or DV snapshots or even a (NOSQL) database. I don't see how this can be done with the current Akka Persistence. The idea of using Akka Streams and Martin's StreamExample look interesting. However, it again seems like infrastructure that needs to be setup for each DV (of which there may be a very large number, each with hundreds of Vs). We also need to be able to recreate the denormalised views (of which there could be a large number) at any time (e.g. due to corruption of a DV or to implement a new DV). I am not sure if Akka Streams will enable this, i.e. to replay all events from all the producers of a stream? I am sorry but I am really struggling to see how the current Akka Persistence will effectively and efficiently work on the read side of CQRS (except in the case of Views based on a single Processor). Remembering that some read models are meant to be a sort of query cache. Again, I hope this makes senses and apologise if it doesn't due to my misunderstanding CQRS or Akka / Persistence. 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.
