saves mucking around managing
> listeners explicitly)
> 3. subclass and return events to sender
>
>
>
>
> On 30 April 2014 14:28, erich oliphant
> > wrote:
>
>> THanks guys,I'd gotten the in-mem journal etc. working, my question was
>>
Hi, I've looked at a few examples where AggregateRoots are implemented as
EventsourcedProcessors, this seems a rather natural mapping and some other
folks posted a pretty elegant solution to a CommandHandler that would front
say a bunch of OrderAggregates. I'm wondering how views dovetail into
t; Note: This is command sourcing only and we are about to do a full sample
> with event sourcing and views.
>
> On Tuesday, April 29, 2014 5:54:53 PM UTC-4, erich oliphant wrote:
>>
>> I've not seen any in the examples (activator, etc). I looked in the
>> tests
I've not seen any in the examples (activator, etc). I looked in the tests
for akka-persistence itself, but not sure what's actually necessary from
that. Do I need to pull-in/create something like PersistenceSpec, etc in
order to test?
--
>> Read the docs: http://akka.io/docs/
>>
I've seen the PersistenceSpec, but not entirely clear on how to use it.
None of the akka-persistence examples I've found (activator,etc) have
actual tests in them.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/curr
t; e.g.:
>> AccountCommandHandler which was responsible to create and route:
>>
>> val account = context.child(accountId) getOrElse
>> createAccountProcessor(accountId)
>> account forwardMsg cmd
>>
>> hth,
>>
>> michael
>>
>>
>> O
Hi, I'm playing around with akka-persistence, and one thing that's not
clear to me is the best way to 1) Handle the command that might create an
instance of a particular event processor (e.g. CreateOrder(...)) 2) Route
commands to the proper instance of the created eventsourced processor (e.g.
.akka.io/docs/akka/2.3.2/scala/persistence.html#Processors>you
> can query recoveryRunning.
>
> Regards,
> Patrik
>
>
> On Tue, Apr 22, 2014 at 12:01 AM, erich oliphant
>
> > wrote:
>
>> Hi, I'm just wondering what, when using the Eventsourcing,et
Hi, I'm just wondering what, when using the Eventsourcing,etc in
akka-persistence, is the best way to handle events that shouldn't be
replayed. Or perhaps better expressed, letting event handlers know a
replay is happening such that those who shouldn't act during a replay
don't. So that say a
