On Thu, Aug 14, 2014 at 6:03 PM, Ashley Aitken <[email protected]> wrote:
> 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)? > That is true, but not a real solution. Right now PersistentView uses the ordinary Recover meachanism, so the journal doesn't really know if it is a view or a persistent actor that is requesting the events. > > 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). > I think you have a good point. That is 3 pre-defined (fixed) tags, and that might be enough. I was thinking that it would be more flexible to be able to define tags, but that might be overkill. > How this is implemented would be up to the store (e.g. duplicate events vs > links). > I agree > > 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. > They must execute in the store to be efficient. Inventing an event query language in Akka that journal plugins must implement is currently out of scope. Some kind of projections can be implemented with Akka streams on top of PersistentViews, and that will be useful, but never as efficient as in running in the store, since all events must be retrieved, deserialized, and so on. > > 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. > Sure. Shouldn't be difficult. Might even be possible today with a custom recovery start message. Please open a specific ticket <https://github.com/akka/akka/issues> about this, so that it is not forgotten. > > Sorry for such long posts :-( > Thanks for the feedback. I will link to this tread from the PersistentView ticket. /Patrik > > 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. > -- 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.
