Hi Ashley, We need something in the journal to make this efficient. Not sure if it is pulling from multiple PersistentActor (new name of Processor and EventsourcedProcessor) or if it is pushing events from the journal (or a combination).
However, the way I would implement it right now is as follows. Let's use your domain Department and Staff. Staff extends PersistentActor. When a Staff actor is updated it publishes a notification event to the "department" DistributedPubSub topic. This is also done after recovery and periodically with a low frequency (e.g. once per minute). The reason for the periodic notification is that those messages may be lost. One the read side we have Department extends PersistentActor that subscribes to the "department" topic. When it receives a notification it creates a child actor StaffView extends View associated to the Staff persistentActorId, if it has not already been created. The StaffView has autoUpdate turned off. Update of the StaffView is triggered by the Department actor via the "department" notifications. Department actor can adjust the update rate. StaffView receives the events of the Staff and forwards interesting (transformed) events to the parent Department actor, which holds an aggregated read model of all Staff actors. Department also stores all persistentActorId, so that it can re-create the child StaffView actors in its recovery. This is not efficient or scalable, but should be working for small systems. For bigger systems I would use Kafka, or implement ticket https://github.com/akka/akka/issues/15004. Cheers, Patrik On Sun, Jun 22, 2014 at 6:41 PM, Ashley Aitken <[email protected]> wrote: > > 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. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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.
