Hi I looked into this question in the past. There are some long threads in the mailing lists and aggregated views seems to be something that will be considered for Akka in the future (unless I misunderstood the threads) but it is only after akka-http and akka-streams are matured.
As for doing something right now, here are some patterns I reasoned about (these would keep the read model in memory in the actor, but that is just a detail): *Pull model:* In the pull model you are piggybacking the event log to double up as a communication bus between services that have no other dependencies. 1. Create a Parent aggregate actor with a hierarchy of PersistentView children. This works best for idempotent information and where eventually consistent is alright and you no requirements on ordering of the messages across the children. 2. Create a Parent aggregate PersistentActor with a hierarchy of PersistentView children. Have each PersistentView child include the sequence id and keep a tally in the PersistentActor of what has been received so far from each child. Drop duplicated messages and on recovery trigger replay in the children starting from the sequence number you have for that view. You now have guaranteed replay ordering that is guaranteed across restarts. You are paying by increased data storage. *Push model:* Akka PersistentViews queries the datasource every 4-5 sek by default. If you worry much about the time it takes for propagation and do not want to hammer the database for quick updates, you can implement a push version of above. Please note that this introduces an extra write for the channel. Instead of having PersistentViews you send the messages from each original PersistentActor over a channel to an Aggregated PersistentActor. The Aggregated actor persists the aggregated view. When you do this what you loose in complexity for not having PersistentView children you pay in complexity by having services that need to know about each other and depends on being up at the same time. Otherwise your dependency is only the data model/protocol at runtime. /Magnus Den tisdag 14 juli 2015 kl. 09:20:29 UTC+2 skrev Amiri Barksdale: > > I've been reading up here on PersistentActor, and I think I get how that > works to perform commands and write the result to an event store. I also > think I understand that PersistentViews can subscribe to a PersistentActor > and receive notification of each event stored for that PersistentActor > type. I want to take a PersistentView and use it to update a separate Read > datastore. > > I don't want to treat the PersistentView itself as a read store, but I > want to make it trigger the creation or updating or saving of a > "projection" of the event in some other store, like, e.g., Elasticsearch or > Postgresql. Are there any guidelines, best practices, or examples of how to > do this? > > One thread ( > https://groups.google.com/forum/#!searchin/akka-user/persistentview/akka-user/rMHjwBZpocQ/SmfAGMg7G68J) > > from June 2014 seemed to indicate that this sort of writing to another > store would require PersistentViews to be able to read from multiple > PersistentActors for this to be feasible. Is this still true? > > What is the path to take here, to get the actor system populating my read > stores? Are people instead creating projections directly from the event > store itself, like Greg Young's EventStore allows? > > Any insight is welcome! > > Amiri > -- >>>>>>>>>> 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.
