4 ms·
Bingo. If you equate this technique to a DB migration, you could have "up" and "down" directions for the translations from version N <=> N+1. Then if you have
by raulk 9y ago
Bingo. If you equate this technique to a DB migration, you could have "up" and "down" directions for the translations from version N <=> N+1.
Then if you have 90% confidence you'll only ever need to replay the upgraded stream, you can upgrade it and destroy the previous version.
If at some point (the remaining 10%) you need to rescue the old stream, you can run the "down" direction and rehydrate the old version of the stream.
- tedmiston 9y agoIt sounds good in theory. In practice, I haven't heard much around running backwards migrations on a data warehouse / massive collection of events but I'm sure some out there already do it.
- dkersten 9y agoI suppose one needs to take care that migrations are never lossy so that the full information for upgrading or downgrading a version is available.
- tedmiston 9y agoYeah, that's the challenge. For instance, how do you handle when a column was one data type but then down the road was changed to another type when the two aren't cross compatible or could potentially break?
- raulk 9y agoYou could retain this info in a meta field of flexible type. For a DB, it could a JSON type. For messages, it could be an extra _meta field on the message that the systems themselves ignore.