3 ms·
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 a
by JustLurking2022 3y ago
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.
- enragedcacti 3y ago> 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.
- fbdab103 3y agoIs 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.