Hi Ashley, most of my response is already in my recent post, what you are describing are topics that are not coupled to a persistenceId and the ability to consume them in other actors as a stream of events since a given position in the log. One thing below resonates with me, and that is that the ability to express queries should be defined by the Journal (backend) implementation and not by introducing up-front categorization using tags. One of the very powerful notions of event sourcing is that you just persist what defines your domain without prior knowledge of the ways you are going to query it later, and tags go against that notion. The event store should provide appropriate filtering options, which in collaboration with the right serializer settings can enable deep inspection of the persisted content (for document-oriented stores).
Regards, Roland 14 aug 2014 kl. 18:03 skrev Ashley Aitken <[email protected]>: > Hi Patrik, > > Thanks for your post. > > On 14 Aug 2014, at 10:31 pm, Patrik Nordwall wrote: > > I think this might fit in rather well with the "tag" based PersistentView. > The Event Store journal plugin could interpret the tag as a projection > identifier. > > Yes, I think that could easily even work now with the journal plugins. What > would these plugins do if a PersistentView was created with a persistenceId > that didn’t correspond to any current PersistentActor but did correspond to a > topic (like the “events” topic in Kafka or a projection in the Event Store > say)? > > However, that said, I have some other concerns with the tag-based approach. > > IMHO, the projections should not require “a priori” event tagging. > Developers should be able to construct just about any projection for the read > side even after the events have been written. Developers shouldn’t have to > think in advance of what tags will be needed later or change code on the > write side. > > As a result of that, it seems to me Akka Persistence should just > automatically tag all events with the type of the actor, the type of the > event, and the actorId (not presuming that all actors will be using the log > for persisting their state). How this is implemented would be up to the store > (e.g. duplicate events vs links). > > PersistentViews for my use-case of denormalisation could just be based on the > actor type, Greg’s example from the other thread could be based on a > combination of event types, and views for truly PersistentActors could just > use the actorId. But there may be some other use-cases people have? > > As you suggest, PersistentViews could just use a label as a projection > identifier. These projections could be rich combinations of possibly > multiple actor types, multiple event types, and multiple actorIds. They > could be specified in the store but it would be nice to eventually be able > to specify them in Akka as well. > > If so, textual tags in each event for these types would be relatively easy > but I don’t think it would be the “Typesafe way” ;-) It would be great to > eventually have a typesafe way of specifying projections that could type > check the components of a projection (and take into account subtyping etc., > e.g. all Customer subtypes). > > And please don’t forget to consider having some way of configuring a > PersistentActor not to receive all events previously persisted each time it > is reactivated. If a PersistentActor is really a “LogProducer” creating a > large log of events, it doesn’t want to have to trundle through all of those > events each time it is reactivated. > > Sorry for such long posts :-( > > Cheers, > Ashley. > > -- > Dr Ashley Aitken > Running Code Productions > LinkedIn/Twitter/Skype: AshleyAitken > > -- > >>>>>>>>>> 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. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> 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.
