I think what GP meant is: what if one of your "indexes" is a SQL database, and over time the shape that database needs to be changes?
In that situation, how do you handle migrations on that database, or building a new copy of it from scratch via the log? Your log will have historical data in a different shape than the schema expects, so you'll end up in an uncomfortable "replay a little, migrate, repeat" situation when reading historical data into the index for any reason.
Comments
I think what GP meant is: what if one of your "indexes" is a SQL database, and over time the shape that database needs to be changes?
In that situation, how do you handle migrations on that database, or building a new copy of it from scratch via the log? Your log will have historical data in a different shape than the schema expects, so you'll end up in an uncomfortable "replay a little, migrate, repeat" situation when reading historical data into the index for any reason.
Normally you version your events, uplift or convert a stream to a updated version.