I have already posted this as an “Issue” on Github but I’ve got no response, so I thought to share it here as well. Pasting the post :
We are currently using EventStore.org as our (shockingly) event store. So far we’ve gone on with the following approach:
- Each aggregate has it’s own Stream, with the naming convention: “AggregateName-AggregateId”
- The Event Type is set to the Assembly Fully Qualified name , so later when we get the event’s back we know the Type and can deserialize the json Data and reconstitute.
However we recently decided for other reasons, to change our Event Type in from the fully qualified name to the simple type name… since the EventType property is in our BaseEvent class, the change got propagated everywhere, including all the way to EventStore, so now our new Streams have the new Event Type. This leaves us with thousands of “old” aggregates / streams, which have the EventType in the old form.
So how should we go about updating (migrating) these old Events ? The article above states that the only option would be to create a new Stream and delete the old one. I’ve tried to do that using the .NET API, it works, but the following thing happens below: (screenshot is of a really old migrated aggregate, please ignore the fact that there are 5 “PartnerRegistered” events, I was doing debugging, and this is the QA environment )
You can see the Event’s numbering has not been reset, it goes on from 5, whereas previously it was 0… also the more worrying thing for me is the Created Date, as you see it’s been reset (of course, as this is a new Stream, with new events…). What are the implications to this approach ? I.e. having all the streams reset like this, with the Creation Date probably identical for all Events in them … it doesn’t seem like a good idea to me, to practice this kind of migration on all aggregates. For us internally, we use a “CreationDateUtc” that we store in the Data payload, so not a problem for us, but I am not sure what the implications are in Event Store (if we were to decide later to use the Projections functionality, or anything else).
Here is a screenshot of a not-migrated aggregate, so you see what I am talking about, the Type column:
So how would you get around this, should should we continue on with deleting and creating of new Streams ? But also, thinking in the future… I understand the theortical arguments of not letting Update operations happen… but maybe we change our classes’ structure (that we deseralize the event’s JSON into… so then we would need the event’s JSON migrated too, how would you get around that ?)
Looking forward to your opinion,