Hi Maatary,
What you persist should be a domain event and contain all information you
need to replay that change, so if you need to fetch data from an external
service then it is very likely that the event should contain that data, or
the result of a calculation with that data. You do not however update the
state using that data (or calculation result) until you have persisted it
and know that it will be replayed if the actor is restarted. So in
pseudocode:
case FetchLastHistoryChangeSet =>
val data = otherService()
// it is ok to read the internal state here, for the calculation
val resultOfCalculation = calculate(data)
persist(EventHappened(resultOfCalculation)) { event =>
// but this is the only place it is ok to change the internal state
updateState(event.resultOfCalculation)
}
I hope this helps
--
Johan Andrén
Akka Team, Lightbend Inc.
On Thursday, April 7, 2016 at 6:09:36 AM UTC+2, Maatary Okouya wrote:
>
> Just for clarification: Where do the execution of a command goes, when the
> execution is not simply a state update (like in most examples found online)
>
> For instance, in my case,
>
> -
>
> The *Command* is *FetchLastHistoryChangeSet* which consist in fetching
> the last history changeset from an external service based on where we left
> off last time. In other words the time of the newest change of the
> previous
> history ChangeSet Fetched.
> -
>
> The *Event* would be *HistoryChangeSetFetched(changeSet, time)*. In
> correlation to what has been said above, the time should be that of the
> newest change of the newly history ChangeSet Fetched (as per the command
> event currently being handled)
>
> Now in all example that i see, it is always: (i) *validating the command*,
> then, (ii) *persisting the event*, and finally (iii) *handling the event*.
>
> It is in *handling the event* that i have seen custom code added in
> addition to the updatestate logic. Where, the custom code is usually added
> after the update state function. But this custom is most of the time about
> sending message back to the sender, or broadcasting it to the event bus.
>
> As per my example, it is clear that i need to do quite few operation to
> actually call*Persist(HistoryChangeSetFetched(changeSet, time))*. Indeed
> i need the new changeset, and the time of the newest change of it.
>
> The only way i see it possible is to do the fetch in the *validating the
> command*
>
> That is:
>
> case FetchLastHistoryChangeSet => val changetuple =
> ValidateCommand(FetchLastHistoryChangeSet);
> persit(HistoryChangeSetFetched(changetuple._1, changetuple._2)) {
> historyChangeSetFetched =>
> updateState(historyChangeSetFetched)}
>
> Where the ValidateCommand(FetchLastHistoryChangeSet)
>
> would have as logic, to read last changeSet time (newest change of the
> changeSet), fetch a new changeset based on it, if it exist, get the time of
> its newest change, and return the tuple.
>
> My question is, is that how it is supposed to work. Validating command can
> be something as complex as that ? i.e. actually executing the command ?
>
>
--
>>>>>>>>>> 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.
