on adding a new command, event sourcing handler is being invoked for all the past events

Imported from Google Groups
#1

Hello,

We notice that in an aggregate, whenever, a new command is issued, event sourcing handler is being invoked for all the past events?

Let’s say we have submitted 6 command to an aggregate and it resulted in 6 events in event store, and then, when we submit 7th command, each time event sourcing handler is being invoked for 6 times and then only the 7th command is being processed, followed by event sourcing handler.

Is it a true observation?

#2

That seems tp be the usual behavior - Im stuck with a use case where I just want to Alter the state of the Aggregate and not execute custom code inside the Aggregate. Not sure how it is possible?

#3

Hi Adita, Hi Sandeep,

@Adipa : your observation is correct and this is the normal behavior for event sourcing. Whenever we want to execute a command against an aggregate, the aggregate is re-hydrated from the events. Therefore, to make sure your projection in memory is up to date, all event sourcing handlers are called one after the other, respecting the order in which the events have been applied previously.

@Sandeep: I don’t have much details in your question, but the unique source of truth regarding your state is effectively the events, so if you want to alter the state of your aggregate, you have to capture the related change with an event to make it consistent in the long run.

#4

Thank you very much. And it makes sense.

So that tells me that I have to start looking into implementing snapshotting.

#5

Hi Aditya,

I am not entirely sure how you’ve landed on snapshotting “to resolve” your problem.
There is no problem with calling all the Event Sourcing Handlers to recreate the state of the Aggregate.
This is completely by definition of Event Sourcing and by design of the framework.

The only thing Snapshotting will add, is that firstly the framework searches for a snapshot of a given Aggregate instance.
If a snapshot is found, the chances are still very high that there are remaining events to be sourced.

I’d lastly like to point out that Snapshotting will only benefit loading times of a given Aggregate once you exceed around a hundred event per Aggregate.
Prior to that, you are only spinning up unnecessary threads and operations to check if a snapshot should be created, stored and read.

Cheers,
Steven