Hi Manuel,
as discussed on LambdaDays today: this won't work, because what guarantees
persist() is meant to give.
Instead you could become() and then do things inside there, or send other
commands to yourself to which the actor should react.
On Thu, Feb 26, 2015 at 11:52 AM, Anders Båtstrand <ander...@gmail.com>
wrote:
> I am not sure I understand what you are trying to accomplish. Don't you
> know the consequences of the state change before you do a persist? You
> could calculate all the changes you want to do, and them persist them in
> order...
>
> Regards,
>
> Anders
>
> fredag 20. februar 2015 14.51.03 UTC+1 skrev Manuel Bernhardt følgende:
>
>> Hi,
>>
>> I'm in a situation where it would be lovely to be able to do a "nested
>> persist", i.e.:
>>
>> persist(SomeEvent)(handle)
>>
>> ...
>>
>> def handle = {
>> case SomeEvent =>
>> changeState()
>> stateChangeConsequences().foreach { _ =>
>> persist(SomeOtherEvent)(handle)
>> }
>> }
>>
>> According to a quick experimentation this does not seem to be quite
>> working. The reason I am looking for this kind of perhaps not entirely
>> ethical behaviour (commands should create events, not event creating
>> events, if I got things correctly) is that I need SomeOtherEvent to be
>> fired right away without giving the chance to someone else to come in (I'm
>> building a reservation system and this part is about waiting-list handling).
>>
>> The other possible option would be to simulate state change and revert it
>> before persisting SomeEvent, but it would considerably complicate the flow
>> (the example above is oversimplified and there's already a simulation going
>> on).
>>
>> Is there any recommended approach for this kind of behaviour?
>>
>> Thanks,
>>
>> Manuel
>>
>>
> --
> >>>>>>>>>> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
Cheers,
Konrad 'ktoso' Malawski
Akka <http://akka.io/> @ Typesafe <http://typesafe.com/>
JOIN US. REGISTER TODAY! <http://event.scaladays.org/scaladays-sanfran-2015>
Scala <http://event.scaladays.org/scaladays-sanfran-2015>
Days <http://event.scaladays.org/scaladays-sanfran-2015>
March 16th-18th, <http://event.scaladays.org/scaladays-sanfran-2015>
San Francisco <http://event.scaladays.org/scaladays-sanfran-2015>
--
>>>>>>>>>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
