Holy hell does that sound awful. In practice, it doesn't even solve the core problem as you'd have to deploy new versions of all binaries precisely in sync to avoid data incorrect because some clients know about the v2 table and others don't. It becomes indistinguishable whether a row is missing because it was intentionally deleted or because it was written by a client who didn't know any the new table version. There are ways to account for this but it's layers of crap on top of crap.
> it doesn't even solve the core problem as you'd have to deploy new versions of all binaries precisely in sync to avoid data incorrect because some clients know about the v2 table and others don't
its painful but this approach does work as long as every client is migrated between each step.
after 1: v1 is valid, reading v1, writing v1
after 2: v1 is valid, reading v1, writing v1 and v2
after 3: v1 and v2 are valid, reading v1, writing v1 and v2
after 4: v1 and v2 are valid, reading v2, writing v1 and v2
after 5: v2 is valid, reading v2, writing v2
after 6: v2 is valid, reading v2, writing v2
at each point, both the current and the previous version are reading a valid table and writing to a table whose values will make it into v2.
Is there really any alternative? Data migrations are always going to be terrible. You need to slowly roll out the incremental changes so that everything is backwards compatible until you the threshold point where you can finally delete the historical route.
