Hi Giovanni: Yes, I suppose you could write directly to a read store in this case. As I wrote in my case I wanted the projection in memory as well to validate conditions before creating output (like allowing the user to download a file).
Amiri: Yes that is correct. The difference between 1 and 2 in the pull model is that order does matter in the second scenario. I tried to describe the second scenario in contrast to the first scenario which is the simple case. Let's say you have a read model where a certain condition might change depending on the order events were read, this particular data depends on multiple events each stored in a separate event log. How do you guarantee that the read model will look the same and that all the decisions you took based on that model previously is still valid next time you create a projection and write a new read model (ie. replay your views from the beginning)? You would need some way to remember the order the messages were retrieved and processed the first time around in the aggregated view when you create your projection. For Get event store my understanding is that they can guarantee ordering across multiple event logs for their aggregated view (a shared global event counter?), I believe Kafka also have this guarantee for their topics. In the case of multiple Akka PersistentActors, each with their own event counter and event log, you don't have this guarantee. If you wish to work around this limitation and have consistent projections were you create a snapshot across multiple event logs that also is reproducible, then you need to record the order your aggregator received the events. I had to give this a good think over again, so thank you for your replies. Not saying the scenarios I described are perfect in any way, just trying to figure out how to do aggregation over event logs without today, when support from the akka libraries are not there yet. :) /Magnus Den onsdag 15 juli 2015 kl. 20:03:46 UTC+2 skrev Amiri Barksdale: > > > On Wednesday, July 15, 2015 at 10:43:55 AM UTC-7, Giovanni Alberto > Caporaletti wrote: >> >> Hi Magnus. >> a question concerning your pull model: if the updates are idempotent, why >> would I need a parent aggregate? Can't the views directly populate the read >> store? >> > > > This is a great question, and I would like clarification on this as well, > because I don't understand how part 1 and 2 hang together after all. It > seems like part 2 of this pull model, with the Parent aggregate > PersistentActor, is actually meant to *impose* an order across the > children. Magnus, is this the case? > > 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.
