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
The entire point of event sourcing is that it is the source of truth. The sourcing in event sourcing.
Otherwise it's not different from a audit log.
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.