You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you call AggregateRepository::saveAggregateRoot, the aggregate got saved and then removed from the identiy map.
I see no reason to do this, because all new events are popped from the stream when saving. One of the main advantages of event sourcing is, that it is append only and because of that its easy to cache.
So e.g. you have a domain event, that triggers some action, lets say on a external API and based on the result it will raise a command on the same aggregate, that caused the event.
Now the aggregate would have to replay the event stream again. In worst case this could happend a few times.
Instead of removing an aggregate from the identity map i would consider its better to add it on creation and keep it on the identity map if its already exists.
IMHO the way the identiy map is implemented right now, it should be without any use.
The text was updated successfully, but these errors were encountered:
We've added an option to disable identity map: #77
and consider removing it completely with next major release.
Aggregates are only cached for multiple reads. In the past it was used to manage a unit of work internally. But we've removed the unit of work to support non-transactional event store implementations. So yes, the identity map is not really used in most cases.
Instead of removing an aggregate from the identity map i would consider its better to add it on creation and keep it on the identity map if its already exists.
If you have a long-running PHP process and keep aggregates in memory without reloading events those aggregates will miss newer events written to the stream by concurrent processes. This would cause weird bugs.
If you want to keep an aggregate in memory and let it process multiple commands without refreshing event history then you have to do it on your end. You can extend from the aggregate repository and store aggregates in your own identity map.
If you call AggregateRepository::saveAggregateRoot, the aggregate got saved and then removed from the identiy map.
I see no reason to do this, because all new events are popped from the stream when saving. One of the main advantages of event sourcing is, that it is append only and because of that its easy to cache.
So e.g. you have a domain event, that triggers some action, lets say on a external API and based on the result it will raise a command on the same aggregate, that caused the event.
Now the aggregate would have to replay the event stream again. In worst case this could happend a few times.
Instead of removing an aggregate from the identity map i would consider its better to add it on creation and keep it on the identity map if its already exists.
IMHO the way the identiy map is implemented right now, it should be without any use.
The text was updated successfully, but these errors were encountered: