First I want to thank you guys for your awesome packages and the hard work you put into them. :heart:

I was trying out this package in local development (Nginx + PHP-FPM, MySQL). After some time this system goes dormant and the next request takes some time to be processed. In this state I (accidentally) made 2 concurrent requests to update the same aggregate. The corresponding controller function:

    public function update(UserUpdateRequest $request, User $user)
    {
        UserAggregateRoot::retrieve($user->id)
            ->updateUser($request->validated() + ['id' => $user->id])
            ->persist();

        return UserResource::make($user->refresh());
    }

This resulted in a duplicate entry in the database, see:

Note: The UserAggregateRoot does NOT have protected static bool $allowConcurrency = true;

Now every update request to that specific aggregate (user) results in the following error:

[2020-11-19 17:39:58] local.ERROR: Could not persist aggregate UserAggregateRoot (uuid: 8be7ace5-8c98-3823-b858-11cdff2974e7) because it seems to be changed by another process after it was retrieved in the current process. Expect to persist events after version 2, but version 1 was already persisted. {"userId":"9e33aa4f-6efa-3505-ab49-9d667e5b2c39","exception":"[object] (Spatie\\EventSourcing\\Exceptions\\CouldNotPersistAggregate(code: 0): Could not persist aggregate UserAggregateRoot (uuid: 8be7ace5-8c98-3823-b858-11cdff2974e7) because it seems to be changed by another process after it was retrieved in the current process. Expect to persist events after version 2, but version 1 was already persisted. at base/vendor/spatie/laravel-event-sourcing/src/Exceptions/CouldNotPersistAggregate.php:18)
[stacktrace]
#0 base/vendor/spatie/laravel-event-sourcing/src/AggregateRoots/AggregateRoot.php(189): Spatie\\EventSourcing\\Exceptions\\CouldNotPersistAggregate::unexpectedVersionAlreadyPersisted()
#1 base/vendor/spatie/laravel-event-sourcing/src/AggregateRoots/AggregateRoot.php(90): Spatie\\EventSourcing\\AggregateRoots\\AggregateRoot->ensureNoOtherEventsHaveBeenPersisted()
#2 base/vendor/spatie/laravel-event-sourcing/src/AggregateRoots/AggregateRoot.php(79): Spatie\\EventSourcing\\AggregateRoots\\AggregateRoot->persistWithoutApplyingToEventHandlers()
#3 base/Modules/User/Http/Controllers/UserController.php(91): Spatie\\EventSourcing\\AggregateRoots\\AggregateRoot->persist()

1. Should this be handled by the package automatically (is this a bug) or should this be prevented in another part of the system?
2. Should I enforce unique constraints in the database on [aggregate_uuid, aggregate_version]? If so, should this be highlighted in the docs?
3. FYI: adding allowConcurrency afterwards to the root allows for updating and inserts a new event with version 3.

Best regards, Marcel

The league/flyststem requirement had to be widened to include ^2.0 as well. However, I noticed that we're not using any code from that package explicitly anyway, so I removed it.

EDIT:

I accidentally based this PR on an older version of the package. I see that it's blocked by https://github.com/spatie/better-types now, as it requires illuminate/collections:^8.58, but I've also opened a PR to address this issue https://github.com/spatie/better-types/pull/2.

This PR introduces backwards compatibility for events that don't have the eventId in their metadata.

Imho eventId shouldn't be in the metadata in the first place. This would also prevent saving, and immediately updating in the EloquentStoredEventRepository. Curious what the thoughts behind this are?

Hi! Love the package!

I'm building custom repositories to store and load events from https://eventstore.com/ so I'm not using Eloquent at all.

I liked the use of StoredEvent, except for the SchemalessAttributes requirement. This type then enforces all of Eloquent to be brought in.

https://github.com/spatie/laravel-event-sourcing/blob/ea48283a7a0db3a5c090de799df8cf01f5918f69/src/StoredEvent.php#L24

At the moment I'm using a workaround, but it's not pretty!

        use Illuminate\Database\Eloquent\Model;
        $emptyModel = new class extends Model { };
        $model = new $emptyModel();
        $model->meta_data = $metadata;

        return new StoredEvent([
            ...
            'meta_data' => new SchemalessAttributes($model, 'meta_data'),
            ...
        ]);

PHP Version: 8.1.5 Laravel Version: 9.11.0 spatie/laravel-event-sourcing Version: 7.2.0

Hi there,

Today I came across the Situation where Method two was getting called when using the AggregateRoot with Method one inside the Application. I wondered why this was happening cause I had never used the AggregateRoot with Method two anywhere yet. After some experimenting and debugging, I found out that this only happens if the Argument in Method two is not type-hinted.

Here are some examples for a better understanding:

Scenario 1 (two is called):

<?php

class SomethingAggregateRoot extends AggregateRoot
{
    public function one(string $foo): self
    {
        ...
        $this->recordThat(new SampleEvent());
        ...
        return $this;
    }

    public function two($without_typehint): self
    {
        ...
        $this->recordThat(...);
        ...
        return $this;
    }
}

SomethingAggregateRoot::retrieve($uuid)
    ->one('laravel')
    ->persist();
// Result: two was called

Scenario 2 (two is not called):

<?php

class SomethingAggregateRoot extends AggregateRoot
{
    public function one(string $foo): self
    {
        ...
        $this->recordThat(new SampleEvent());
        ...
        return $this;
    }

    public function two(boolean $with_typehint): self
    {
        ...
        $this->recordThat(...);
        ...
        return $this;
    }
}

SomethingAggregateRoot::retrieve($uuid)
    ->one('laravel')
    ->persist();
// Result: two was not called

Is this an expected behaviour or a bug/defect?

Thanks for checking and clarifying, Fabian

My first time using v7 of the package, and had some issues with aggregates last night.

Could not persist aggregate PostAggregate (uuid: 19dad81e-b6ab-4012-a04a-401e1d35747d) because it seems to be changed by another process after it was retrieved in the current process. Current in-memory version is 1

Using Laravel 9.2.0 PHP 8.1

Aggregate:

class PostAggregate extends AggregateRoot
{
    protected static bool $allowConcurrency = false;

    public function createPost(DataObjectContract $object): self
    {
        $this->recordThat(
            domainEvent: new PostWasCreated(
                object: $object,
            ),
        );

        return $this;
    }

    public function getStoredEventRepository(): StoredEventRepository
    {
        return app(PostStoredEventsRepository::class);
    }
}

Event:

class PostWasCreated extends ShouldBeStored
{
    public function __construct(
        public readonly DataObjectContract $object,
    ) {}
}

Service Provider:

class EventSourcingServiceProvider extends ServiceProvider
{
    /**
     * @return void
     */
    public function register(): void
    {
        Projectionist::addProjector(
            projector: PostHandler::class,
        );

        Projectionist::addReactor(
            EmailModerators::class,
        );
    }
}

Projector:

class PostHandler extends Projector
{
    public function onPostWasCreated(PostWasCreated $event): void
    {
        /**
         * @var CreatePostContract
         */
        $action = resolve(CreatePostContract::class);

        $action->handle($event->object);
    }
}

The event is persisted in the database during testing with no errors, but when I interact with my code from the web UI - I get this issue. The aggregate is being triggered by a Livewire component that uses a service class to trigger the aggregate:

Livewire Component:

class CreateForm extends Component implements HasForms
{
    use InteractsWithForms;

    public bool $moderation = false;
    public null|string $title = null;
    public null|string $description = null;
    public null|string $content = null;
    public null|int $category = null;

    public function mount(): void
    {
        $this->form->fill();
    }

    public function submit(
        PostFactoryContract $factory,
        PostAggregateServiceContract $service,
    ) {
        $service->createPost(
            $factory->make(
                attributes: array_merge(
                    $this->form->getState(),
                    ['user_id' => auth()->id()],
                )
            )
        );

        return redirect()->route('dashboard');
    }

    protected function getFormSchema(): array
    {
        return [
            Grid::make(4)->schema([
                TextInput::make('title')->label('Post Title')->columnSpan(2)->required(),
                Select::make('category')->label('Post Category')->options(Category::get()->pluck('title', 'id'))->columnSpan(2)->required(),
                TextInput::make('description')->label('Post Description')->columnSpan(4)->required()->maxLength(120),
                MarkdownEditor::make('content')->label('Post Content')->columnSpan(4)->required(),
                    Toggle::make('moderation')->label('Submit for moderation')->columnSpan(4),
                ]),
        ];
    }

    public function render(): View
    {
        return view('livewire.posts.create-form');
    }
}

Service class:

class PostAggregateService implements PostAggregateServiceContract
{
    public function createPost(DataObjectContract $object): void
    {
        PostAggregate::retrieve(
            uuid: Str::uuid()->toString(),
        )->createPost(
            object: $object,
        )->persist();
    }
}

As you can see the service class tries to persist the aggregate, and this is where it fails. In my test code all I am doing is making sure that the event is stored:

it('triggers the aggregate root to store the event that a post was created', function () {
    $category = Category::factory()->create();
    auth()->loginUsingId(User::factory()->create()->id);

    expect(PostStoredEvent::query()->count())->toEqual(0);

    Livewire::test(CreateForm::class)
        ->set([
              'title' => 'pest php',
              'category' => $category->id,
              'description' => 'pest PHP is awesome, prove me wrong',
              'content' => 'Here be content, pirates and dragons',
          ])->call('submit')->assertHasNoErrors();

    expect(
        PostStoredEvent::query()->count()
    )->toEqual(1);
})->group('publishing');

As per this comment, in V5 the issue that caused the need for re-resolving was fixed. This PR removes that temporary fix in favor of Projectionist::fake() calls.

@brendt I can imagine this is a breaking change for a small percentage of users, so would require a new major release. I don't think there is a branch for v6 already?

https://github.com/spatie/laravel-event-sourcing/discussions/181

When applying the custom directory structure as suggested by the "Laravel Beyond Crud" book, the event discovery fails as it uses the base path to guess the class names from the file names.

https://github.com/spatie/laravel-event-sourcing/blob/05d0aa072ac6385aebda0d84519a8aa389fe2813/src/Support/DiscoverEventHandlers.php#L72-L83

So a Projector placed at ./src/App/Projectors/UsersProjector.php is guessed as this class Src\App\Projectors\UsersProjector, which does not exist.

By allowing a user to specify a custom config key one could add this config key:

'auto_discover_base_path' => base_path('src'),

And have the src part ignored.

As it is seems to be an edge case, I didn't add a config key on the config stub.

If you prefer me to do so, please let know and I will update the PR.

More reasoning here: https://github.com/spatie/laravel-beyond-crud-demo/issues/7#issuecomment-792965120 (private repo)

EDIT I pushed more commits to allow for a more descriptive config key

I ran into a situation where I needed to retrieve an aggregate for a specific state in the past. This PR adds an optional 2nd argument to the Aggregate Root, so it's possible to get a previous state of an aggregate, instead of just the latest.

A concrete use-case is when trying to compare a previous state to the latest state, exactly like this PR 🥁

I also believe this is another solid use case to use aggregates, in addition to the other benefit of making decisions based on past events.

Here's how it would work with this PR in place:

$account = AccountAggregate::retrieve($uuid, 3);
return $account->balance;

Since this is an optional argument, there should be no breaking changes. I also added the argument to AggregateRoot::loadUuid, for consistency.

Let me know what you think and if the PR needs any tweaks.

Co-Author: @lukecurtis93 Credit: Quality checked against https://github.com/spatie/simple-excel/pull/43 due to https://twitter.com/freekmurze/status/1337047675611582464

Hi,

according to the changelog, 1.1.0 is supposed to contain the change countAllStartingFrom. But after updating with composer to 1.1.0 the package now requires PHP 7.4 (the major change of v2). It also doesn't contain the changes related to countAllStartingFrom.

It looks like the tag has been related to a wrong commit, it points to a merge commit on the master branch.

I'm not sure, what the best way would be to solve this. It's just that at the moment 1.1.0 doesn't contain the desired feature, and depends on PHP 7.4 ...

Changed the event_version column type from int to unsigned tinyint in the stored_events table migration stub.

The event version shouldn't be negative, therefore, the new column type would be more semantically correct for the use-case of this feature

I'm playing around with this package and noticed, that when following the documentation for aggregate partials and creating a snapshot of the aggregate root, the state of the partial is not stored in the snapshot. Not sure if that is intended or a bug, as I didn't find a test for this usecase and the documentation didn't mentions snapshots and aggregate partials.