How do you manage event message versioning?

[Ruslan Uralov]

Hi all,

The question relates to Event Sourcing, but since this approach is often used together with Disruptor i thought i'd ask it here.

Since event log produced by the Journaler is the single view of application state, how do you manage event message versioning? 

Lets say you had a message with fields 1 and 2. You ran your application and message was persisted by Journaler. If you don't make any changes to message you can replay message log and get to original application state. But then you decided that this same message has to have additional field 3 and it no longer requires field 2 or 1. What do you do in this case? Additional fields can be easy if they may have a sensible default value, what about field removals? Do you still read in the value into a field, but don't actually use that field? This may unnecessarily obfuscate your code. Or do you create a completely new message type for these scenarios?

Many thanks,

Ruslan

[Michael Barker]

The short answer is that we don't. At release time we quiesce the
system and archive off the journals. We rely on a clean shutdown and
snapshot to remove the need to recover back past the last release.
Only the snapshot is migrated.

Mike.

> --
> You received this message because you are subscribed to the Google Groups
> "Disruptor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lmax-disrupto...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>