Reconstituting a specific version about eventsauce HOT 8 CLOSED

Hi @Toflar :)

This functionality is currently not included in EventSauce. The main reason for this is that an aggregate root is responsible for making decisions and should do that based on the latest info. Going back into history is something that would be possible by making using read-models that directly read from the message repository.

Perhaps you can explain what specific case you're trying to support. My guess if that you're using the aggregate root for reads, which is generally a bit of an anti-pattern. But curious to hear what your specific case is all about.

from eventsauce.

The idea would be that the projection would resolve the messages from the repository when asking for the state at a given point in time, so no need to pre-compile it for every step. Basically it would be as expensive as loading two aggregate roots, which should be quite alright.

from eventsauce.

Defintely, thanks!

from eventsauce.

I see your point. It really is a read operation so it should probably indeed not be part of the aggregate.
Basically I'm working on some POC for a general content repository to store whatever content. If you check my OSS contributions on GitHub you can kinda guess where I'm coming from 😉 We're talking CMS stuff here.
And I think a typical use case would be a user that wants to compare the current version of a content node with the previous one or the one of 30 days ago etc.
So having a projection for that sounds a bit inflexible because projections require to know in advance what the user would want to compare.

from eventsauce.

Yep, that's what I did now and it works perfectly 😉 Thanks!
Since the EventSauce docs are so well written, what do you think of an FAQ section for questions like this? I could of course contribute 😊

from eventsauce.

Awesome, yes. We can can create a section for case studies, or common problems with solution. Contribution would be much appreciated.

from eventsauce.

#180 :)

from eventsauce.

I'll consider this fixed with the addition of the documentation :)

from eventsauce.