On Thursday, October 19, 2017 at 9:33:59 PM UTC+2, Patrik Nordwall wrote:
>
> Invalid events must not be stored, because then the actor will not be able 
> to recover after a restart (later startup). Validation should typically be 
> done by validating the incoming command before persisting the event. 
>

That depends on what you mean by invalid event:
 * completely invalid event within state
 * valid event that does not change state
 * given batch of events, and some of them are invalid, what to do with 
others?
 

> Validation should not be placed in applyEvent, but as an additional 
> protection in case applyEvent throws exception (for validation or other 
> reasons) we have chosen to call applyEvent before calling persistAll.
>

For instance we would like to avoid exceptions, thus we have `state: 
Either[Error, State]` and validation result is also of type `state: 
Either[Error, State]`
 

>
> I'm not sure I understand what you are missing or suggest should be done 
> differently, so please clarify. Isn't the problem that you mix the concerns 
> of validating cmd/event with applying the event? If you have a separate 
> step for validation you can do that before persisting, and the applyEvent 
> is intended purely for changing the state and cannot fail.
>

Let's consider we want to avoid exceptions, thus we have verified that 
event can be applied to state and then either return PersistentActor.persist or 
proceed further without persistence.
However now we cannot avoid useless in our case call `state = 
events.foldLeft(state)(applyEvent)` as we had to do that on our own already.
 
So I propose to remove concept of `state` from command handling phase, and 
have similar to typed actor approach with Behavior

And the transition might look like `onRecoveryCompleted: State => 
PersistentBehavior[Command, Event, State]`


What do you think ?


> On Thu, Oct 19, 2017 at 5:48 AM, Yaroslav Klymko <t3h...@gmail.com 
> <javascript:>> wrote:
>
>> I also have other concern regarding.
>>
>> case PersistAll(events) ⇒
>>   // apply the event before persist so that validation exception is handled 
>> before persisting
>>   // the invalid event, in case such validation is implemented in the event 
>> handler.
>>   state = events.foldLeft(state)(applyEvent)
>>   persistAll(scala.collection.immutable.Seq(events)) { _ ⇒
>>     sideEffects.foreach(applySideEffect)
>>   }
>>
>>
>>
>> We have local practice to apply events before persisting to make sure 
>> those are valid and then reusing resulting state.
>> We also have explicit logic on what to do with event that is not valid - 
>> Keep | DropEvent | DropCmd
>>
>> But this logic enforces users to apply events after persistence and rely 
>> on exceptions.
>>
>>
>> Please let me know in case I'm wrong, I'd really like to understand your 
>> logic :)
>>
>>
>> On Wednesday, October 18, 2017 at 10:28:43 PM UTC+2, Yaroslav Klymko 
>> wrote:
>>>
>>> I think renaming 
>>> actions:       State => Actions[Command, Event, State]
>>> to
>>> onRecoveryCompleted:       State => Actions[Command, Event, State]
>>>
>>> Makes it really clear. Also you might just decide to stop the actor in 
>>> case the state is wrong, etc.
>>>
>>> On Wednesday, October 18, 2017 at 10:22:12 PM UTC+2, Patrik Nordwall 
>>> wrote:
>>>>
>>>> Do you suggest something like this?
>>>>
>>>>   def immutable[Command, Event, State](
>>>>     persistenceId: String,
>>>>     initialState:  State,
>>>>     actions:       State => Actions[Command, Event, State],
>>>>     applyEvent:    (Event, State) ⇒ State): PersistentBehavior[Command, 
>>>> Event, State]
>>>>
>>>> I it would be rather difficult to understand what state that is, 
>>>> especially since there is also Actions.byState. A typical usage of 
>>>> onRecoveryCompleted is to perform side effects, such as resending to an 
>>>> external service, and it's better to not mixing that concern with the 
>>>> construction of the command handlers.
>>>>
>>>> /Patrik
>>>>
>>>>
>>>> On Wed, Oct 18, 2017 at 2:54 PM, Yaroslav Klymko <t3h...@gmail.com> 
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>> Not sure this is the right place to ask:
>>>>> I'm looking into akka typed for persistence and wondering whether we 
>>>>> really need onRecoveryCompleted at 
>>>>> https://github.com/akka/akka/blob/master/akka-typed/src/main/scala/akka/typed/persistence/scaladsl/PersistentActor.scala#L174
>>>>> Why not just have something like actions: State => 
>>>>> PersistentActor.Actions[Command, Event, State] ?
>>>>>
>>>>> -- 
>>>>> >>>>>>>>>> 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 akka-user+...@googlegroups.com.
>>>>> To post to this group, send email to akka...@googlegroups.com.
>>>>> Visit this group at https://groups.google.com/group/akka-user.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>>
>>>> Patrik Nordwall
>>>> Akka Tech Lead
>>>> Lightbend <http://www.lightbend.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 akka-user+...@googlegroups.com <javascript:>.
>> To post to this group, send email to akka...@googlegroups.com 
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to