You may be a racist.
4 karma · joined June 4, 2015
It's not about abusing the diff. It's about diff being fundamentally the wrong technique to transition from state (C)urrent -> (T)arget.
A diff cannot always bring you to the desired T. The diff only factors in 2 states (C and T) and not X,Y,Z which you may have an import from and which may need to occur during a transitional state before T is reached.
It doesn't factor the desired state T may not even exist to diff against if developers move forward adding objects not for this release. It makes things easier on web developers at the expense of deployments.
Which "scales" better? Migration tools scale better at letting web-devs free wheel in the DB.
For bullet proof deployments migration tools don't scale. They excel at the simple cases but hit a hard limit.
BTW any details on what kind of data in production broke a deployment? Heads up to avoid it myself.
Migration frameworks work on diffing dev with a copy of the deployment target. This is inferior. If you rename a table it may drop the table losing all data, then create a new one. It has no way of knowing a rename from 2 unrelated tables. It includes junk/testing objects that should never pollute proudction.
Hope your bank is not using one of these migration frameworks.
Nubmered scripts are the way to go. With a strict policy to never update a script, only create new ones. You're modifying state, so you must capture ordered steps that moved you from state 1 -> 2. This will avoid a host of subtle issues. After a release you can create a backup as a baseline for the next set of scripts to run against.
But your focus on the language over the product is wrong. Google built their empire on crusty old boring C++. No fancy live interactive coding. Language only makes you happy. The product makes the user happy.
>meaning "cleverness" and ingeniare
>meaning "tocontrive, devise"