Hi Tal,
I've implemented the original Persistent FSM PR, I'll try to answer your questions. 1. The same is true for the regular PersistentActor, it probably wasn’t important enough. 2. It’s needed to handle the events on recovery. PersistentFSM saves 2 types of events: state change events and domain events of type E. This class tag was needed to pattern match the domain events on recovery. 3. replying is defined in the regular FSM state and PersistentFSM tries to follow the same contract/signiture. Instead you can use andThen for this. It accepts the callback with a signature - nextData ⇒ Unit. See this example: http://doc.akka.io/docs/akka/2.5.3/scala/persistence.html#a-simple-example Thanks, Leonid On Wednesday, August 16, 2017 at 8:51:36 PM UTC+3, Tal Pressman wrote: > > Hi, > > We've been using Persistent FSMs for a while now, and really like them - > the combination of the structure and functional state with event sourcing > is really useful for us in many cases. > > However, there are some places where the API feels a bit strange, or that > it's missing some things, and I would love to either understand the > motivation/logic behind it (or to create a PR fixing them ^_^ ) > > 1. PersistentFSM uses the Event matcher from FSM. However, in > PersistentFSM (and event sourcing in general), event already has meaning. > I > think it would be clearer if this was called Command. > 2. implicit domainEventClassTag - this one is a constant source of > trouble, and I don't really understand why it's there. The trouble is that > when using IntelliJ, and telling it to generate overrides for > unimplemented > methods, the generated method declaration includes the 'implicit'. This, > together with the usual implementation (classTag[Whatever]) causes an > infinite recursion ending with stack overflow. At the same time, I don't > understand why this method is even necessary. Wouldn't defining the Event > type parameter as E: ClassTag be enough? > 3. There are many cases where, in the state function, it would be > useful to know what the "next data" would be. For example, consider an FSM > with a state waiting for N responses and counting the received responses > in > the data. You would have to either duplicate the logic (here it's simple > counting, but there are obviously more complex use-cases) or need access > to > the data after applying the generated event. Now, I understand why this is > the way it is, and why it would be impossible (without access to a time > machine) to properly "solve" this. So for deciding on which state to > transition to, or which events to emit we have to accept it. However, > there > are some specific things (like the "replying" part of the state) where I > think a more convenient API could be provided (replying could take a > function from nextData => reply). > > (Yeah, this post should probably have come back when the persistent FSM > API was being finalized, but better late than never?) > > Thanks, > Tal > > -- >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
