Thank you very much. Yes it does. Pretty much what I needed to know.
I believe now the question is more about how to deal with making it non
blocking. The call to an external service should not block the thread.
Hence will be a future. But to not block on that, one needs some specific
code for that right?
Like using become/unbecome stash/unstashAll.
I wish this was somewhat natively supported because it is definitively
going to happen all the time. Having to repeat this tricky code everywhere
is simply not elegant.
On Thu, Apr 7, 2016 at 12:06 PM Johan Andrén <johan.and...@typesafe.com>
wrote:
> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/zhTn7huXLKg/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>
--
>>>>>>>>>> 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.
