Comments on: CQRS – Event Versioning

By: dokie

dokie — Thu, 25 Feb 2010 17:22:04 +0000

@Mark Nijhof
Do you mean the version number of the reconstructed AR is compared to the version number in the store on point of save? This stops a group of cases where that wondow for concurrency error is (usually) small. How does this help with the scenario where the command received would overwrite the previously written AR which may have also been valis – e.g. If 2 users change the address but to different values (ignore why that might happen for now) then depending on whose Command gets there last, their changes will win since the Command does not carry any version information over from the Query side.

I may also be confused by your reply though so apologies if so and would appreciate a clearer explanation.

By: Mark Nijhof

Mark Nijhof — Tue, 23 Feb 2010 14:34:04 +0000

@Sebastian Concurrency issues are dealt with by verifying the version numbers of the AR in the event store and the AR you have. If they do not match then you have a concurrency valuation. Now because we work with commands and events we can (if you handle this smartly) automatically solve some of these issues. For example if these two different commands result in different state changes then we could allow the version conflict to be ignored. Greg is going to write a post about this as well, and I am planning on creating a test case where this becomes visible.

By: Sebastian

Sebastian — Tue, 23 Feb 2010 13:29:43 +0000

Hi mark,

Thanks for your response. I would really appreciate to get clarified how to deal concurrency issues in CQRS when not using RDMS as the event storage mechanism since I still see this field in color grey
Thanks for your blog and for takin down everything to code examples, that really makes things understandable and gives a clear picture of the whole.

Cheers.

By: Mark Nijhof

Mark Nijhof — Mon, 22 Feb 2010 18:58:03 +0000

@Sebastian I used adding a property to the event as a simple example, and in this case you might be right it doesn't need a new event, except if you want to track these things as well. But I am sure there are many more ways these things evolve during the lifetime of a system. Versioning the events this way is a good way of dealing with these changes.

By: Sebastian

Sebastian — Mon, 22 Feb 2010 18:33:01 +0000

Hi Mark,

As long we add data to events we agree we have to reflect that as a new property in the AR. I don’t see any conflict for the case of appending data to events since the new property will be Null until set. So why the need to create versioned events instead of appending new properties to the same event class?
On the other hand, if we design an event to hold 3 attributes and after system usage we got a requeriment to delete 1… we do will have to change code where that deleted property where set (in the AR), however we might leave the event with those 3 atributes where 1 of those would be redundant and will no afect the AR behaviour since no longer will be reflected into the AR.
However for this case, of deleting attributes I do see the benefit of “prunning” or “clearing” events using converters but I don’t achieve to see the benefit for the reverse case of appending data to events.
Cheers.

By: Mark Nijhof

Mark Nijhof — Mon, 22 Feb 2010 09:58:37 +0000

@Kaarel
That is an interesting issue! And the obvious answer is “it depends”

But do you want to keep track of the CC# meaning like Amazon to enable fast purchases? Then you just need it in the reporting database, and deleting from there is a non-issue. But in-order to get it there you need to fire of an event. So I would suggest adding an attribute on the event that indicates the event store to skip storing this event. Because the rule is that you don’t touch events once they are in the event store.

Now if you are forced to do change your events in the event store by law, then you don’t have a choice, in that case I would just go in and just change the CC# within those events, so all other information stays intact and you still keep track of what happened when. But it is not optimal, and you would have the same issue with other auditing solutions.

So if upfront you know something like this is a requirement then I would opt for skipping these events, also I would want them to be containing only the absolute minimum needed information, or perhaps even double sent the event one with CC# and one without, with CC# will not be stored, without will be.

But this is just me thinking about it, all situations are different.

Hope that helps

By: Kaarel

Kaarel — Mon, 22 Feb 2010 09:39:29 +0000

How do you handle sensitive data when using event sourcing? Do you store credit card numbers in the event log? What if you have to delete all data related to an entity? Say to comply with data protection rules or court order and you have to remove all historical data for some entities (but not all) in your system. Wouldn’t that mess up your event log and auditing?

By: Mark Nijhof

Mark Nijhof — Fri, 19 Feb 2010 20:07:25 +0000

@Chad
You keep the events because they offer business value, either in the ability to gather more information from your data, or as an audit log. If you would go and start changing these historical events you introduce the possibility that you make a mistake. And your audit log becomes invalid. So depending on how important those features are for you you might decide to ‘break the rules’.

But before you do; once you have a mechanism to convert events from one version to an other version this becomes easy. You can also issue one time compensating events if you run into a change that you cannot manage naturally. So I would like to argue that it is not very difficult, and that changing existing events might introduce more pain than you may gain.

The binary formatter indeed means that you need to keep the events in the same namespace, but that is only one way of serializing, I recommend creating a custom formatter disconnecting yourself from the namespace issue and also increasing speed and minimizing space. And consider using an other medium to store the events, like using CouchDB or something like that.

But to answer your last question, I wouldn’t go into the historical events and change them, I rather version them and deal with that issue.

By: Chad

Chad — Fri, 19 Feb 2010 19:40:33 +0000

I can see how a method like this would work well for simple changes like the one you described. But how would you handle big changes?

For instance, say that we do a big refactor and we rename/move/merge/split some of our events. Having to keep those “old” events around along with the newly refactored events seems like it could get messy fast.

Or say we do something simple like just rename an assembly or a namespace. I’m pretty sure that would break the binary serializer and I wouldn’t want to have to keep that old assembly lying around indefinitely just to support those legacy events in the event store.

In this case, wouldn’t it be ok to modify the event store and migrate the old events to the new events – as long as the semantic meaning of the events is still the same?

And if so, is there an easy way to go about performing such a migration assuming the events are binary serialized somewhere?

By: Szymon Kulec

Szymon Kulec — Thu, 11 Feb 2010 20:46:48 +0000

Mark,
according to the conversation with @seagile, you want to keep all the events versions in your code, am I getting it right? Wouldn’t xml serialized versions of them be enough for the mentioned audit log?
The second think is a case, when the newly added property, for instance AtmId cannot be null nor empty. What about this case? Or maybe new properties should always allow default(T) values to be set? One of the aspects of event sourcing is the ability to undo and redo the events execution. What if the undo moves the history to the point when an event has a nulls_not_allowed property set to null? Is this kind of situation possible at all?

Who’s the nagger?