3 ms·
I find this sort of practice absolutely bizarre. A bit like flying a plane to your destination with a compass and stopwatch rather than simply looking out the
by djrobstep 7y ago
I find this sort of practice absolutely bizarre.
A bit like flying a plane to your destination with a compass and stopwatch rather than simply looking out the window or at the GPS.
Migrations should be checked against the current production schema directly, not by retracing historical steps.
There are two states you care about: current production, and desired production.
There is one migration you care about: the one between production and desired.
Involving anything else is pointless complexity for no reason.
- zerd 7y agoI disagree. If you have test environments only tracking "current" and "desired" doesn't hold up, then you would need different diffs for each environment. Making sure they all apply the same migrations in the same order is important to avoid drift and ensuring consistency. Also an issue if you have multiple production databases, e.g. sharding. When you have lots of migrations and you're sure all environments are up to date to a certain point you can "squash" the initial ones to make it apply faster.
- djrobstep 7y agoI don't see the problem. Each branch has its own desired state as necessary. A different database version is going to need a different migration script, no matter what your approach. Only difference is whether you generate those scripts by direct comparison with prod directly or with a crude reconstruction of it.