Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <55B94989.5040103@gmail.com>
References: 
 <CADmm+Kd6oCa8Lhg6p_i7qhg1R6myjANmn5srp62UXM4rP76OBg@mail.gmail.com>
 <55B3F8D8.7000305@gmail.com>
 <CADmm+KcJTOeMBhrYBmR=004FeF1OUUjEd2SbfmSrQAKhSBVwYg@mail.gmail.com>
 <55B94989.5040103@gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Thu, 30 Jul 2015 09:35:55 +0800
Message-ID: 
 <CADmm+Kd=YYTQvY7jjVctoRaPzoUS-T_BUvvyKmOCe2LiNvugzQ@mail.gmail.com>
Subject: Re: [Proposal] EventSourcing support
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a1132f682a2b71e051c0dba21

--001a1132f682a2b71e051c0dba21
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Right now, I only want to rehash the last point, about "replay of past
events".

I think you misunderstood my point. SO let's look at an example;

Let's say that the model is a bank Account, which only has
"AmountDeposited" and "AmoundWithdrawn" events in it. And these events are
generated as notifications to other Aggregates to react on.

Later on, it is detected that another system was expecting
"AccountOverdrawn" and "AccountRecovered" events when the balance goes
below zero (and comes back above zero), but the Account has the bug that it
is never emitting such event.
I.e. this is a "derived event" and in all the event-driven systems that I
have written, it is very common, more the norm than the exception.

So, if the events are replayed (properly replayed, at system level and not
only aggregate level for state restoration), then new events would be
generated.

IIUIC, the current EventSourcing library has a problem with "derived
events" too. Since the "record/replay" mechanism is intercepting/injecting
the Event methods, any call from one Event method to another Event method,
would result in execution of the second event method twice, first from
being a derived event, and secondly from the previously recorded event,
unless de-duplication is happening, AND that Event equals() never changes
over time.

It feels to me that there is something not quite right, but I can't put my
finger on it yet.

Niclas

On Thu, Jul 30, 2015 at 5:45 AM, Kent S=C3=B8lvsten <kent.soelvsten@gmail.c=
om>
wrote:
>>
>> Let's ponder about "replay of past events"...
>>
>> EventSourcing prides itself that one can change the algorithm, replay th=
e
>> events and hence retro-actively fix bugs in the past. BUT, what happens
if
>> the new algorithm emits new events, but in past time? Should those be
>> injected into history? Or vice versa, what if the bug was that too many
>> events were emitted, should those now be removed? Or is it that ONLY the
>> State Resolver is allowed to be modified, and that the replay is
>> effectively "never" happening as a global thing, but just internally in
the
>> Aggregate Root whenever its state is loaded??
>>
>> I bet that this has been discussed endlessly on various forums, and I
>> should probably go digging.
> I remember Greg Young discussing that past events should never be
> modified - but new compensating events might be added to the history (If
> money are transfered from a bank account by a mistake, the transfer is
> not deleted - instead a compensating transfer is added).
>
> I think we should simply disallow nesting events - so replaying an event
> can never emit other events. And otherwise the problem to the
> applications - and wait and see if anything more should be done to ease
> their task.


--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--001a1132f682a2b71e051c0dba21--