Can we permit custom created_at's in our ShouldBeStored & EloquentStoredEvent events for testing?

[steven-fox]

Opening Question:

Is there a reason why the package overwrites a ShouldBeStored event's created at value at the AggregateRoot::recordThat() and EloquentStoredEventRepository::persist() methods?

I understand it's important that events get stored in a chronological order, but this discussion is purely for tests.

Background
We have some business logic that is based on the time-frequency of events occurring. Thus, to test that this time-dependent logic is implemented properly, I'd like to make tests that load up events that are simulated to have taken place over a specified duration. As a quick example, imagine needing to write a test for an EventQuery report.

To accomplish this, I thought it would be as simple as crafting some ShouldBeStored events, using the $event->setCreatedAt() method to specify what I want, and then passing that through an AggregateRoot for the normal recordThat() and persist() process.

However, it turns out the package will overwrite the ShouldBeStored event's created at value in 2 places:

1. laravel-event-sourcing/src/AggregateRoots/AggregateRoot.php

   Lines 94 to 96 in e8decf4

   	$domainEvent
   	->setAggregateRootUuid($this->uuid)
   	->setCreatedAt(CarbonImmutable::now());

2. laravel-event-sourcing/src/StoredEvents/Repositories/EloquentStoredEventRepository.php

   Lines 83 to 94 in e8decf4

   	$createdAt = Carbon::now();
   	$eloquentStoredEvent->setRawAttributes([
   	'event_properties' => app(EventSerializer::class)->serialize(clone $event),
   	'aggregate_uuid' => $uuid,
   	'aggregate_version' => $event->aggregateRootVersion(),
   	'event_version' => $event->eventVersion(),
   	'event_class' => $this->getEventClass(get_class($event)),
   	'meta_data' => json_encode($event->metaData() + [
   	MetaData::CREATED_AT => $createdAt->toDateTimeString(),
   	]),
   	'created_at' => $createdAt,

Possible Solution?
Therefore, with the primary purpose of easily allowing a test to build a sequence of events that "took place over time", it seems like we could update those lines to respect a ShouldBeStored event's meta_data.created-at value if it's not null.

// AggregateRoot::recordThat()
$domainEvent
    ->setCreatedAt($domainEvent->createdAt() ?? CarbonImmutable::now());

// EloquentStoredEventRepository::persist()
$createdAt = $event->createdAt() ?? Carbon::now();

Current Remedy
For my current tests, I'm manually instantiating the EloquentStoredEventRepository and telling it to persist() custom events. Right afterwards, I then use the returned StoredEvent and update it's created_at and meta_data.created-at values. It works, but it's clunky and I have to bypass the aggregate root (meaning I also have to handle the aggregate_version attribute).

Could something like this work? Is there a different way that we should be testing this?

Thanks for your time,
Steven - an Event Sourcing Course customer

[sandermanneke]

I have a similar need but to set the createdAt date and correct the aggregate version but not for testing purposes.

My events for an aggregate root are triggered by polling data out of multiple external API's, each datar ow has an evenDate when it happened in the external system.

I need to preserve the timeline order in which events occurred, but without being able to dictate the createdAt date fore stored_events I end up with events based on insertion date and not on the date it actually happened in the external system.

Has anyone been able to solve this?

Or am I approaching this in the wrong way?

[steven-fox]

Hey @sandermanneke. For your situation, I believe it's best to set a custom attribute within the event_properties on the stored event that holds the external datetime you need to work with, thus leaving the created_at date alone.

As a rough example, it'd be like having an event called PolledExternalApi where that event has a property of externalEventDate that corresponds to the external system's timestamp for that datarow. Your history of PolledExternalApi would then be in order according to when your system performed the polling request, and you could perform additional logic/processing on the stored externalEventDate to do the follow up things you need.

Don't forget that event sourcing is meant to be a replay-able transaction log of things that occurred with your system, and those events can (and should) lead to the storage of other database records. So when a PolledExternalApi event occurs and you have a datarow you want to store, you may want to set up a Reactor and Projector to translate that external data into a dedicated database table within your system.

Hope this helps.

[sebastiandedeyne]

I agree that the way we set created_at in multiple places is messy and hard to overwrite. This is something I want to reconsider in the next major version, but I'm wary about making changes now.

That said, in my own projects I avoid using the packages created at altogether. I see createdAt as a technical piece of meta data of when the event entered the system, not when the event occurred.

I often add an occurrence date to my events if to access in my code, like OrderPaid::paidAt. Reason is when a user wants to create or import backdated data, we can keep the event's createdAt as is and specify the business-related date in the event with the other data.