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.
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.
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.
On Thu, Oct 19, 2017 at 5:48 AM, Yaroslav Klymko <t3h...@gmail.com> 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/b
>>>> lob/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/c
>>>> urrent/additional/faq.html
>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>>> p/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+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.
>
--
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.
