SchemaSmith Documentation
Migration Scripts
Handle any edge case with confidence.
Handle any edge case with confidence.
While SchemaQuench can automate much of the updating process, there will always be edge cases that it cannot support in an automated fashion. Changing a column to non-nullable without a default is an example. You need a way to update any null values before changing the schema.
Migration scripts provide a way to make those types of changes both before and after the schema changes are applied. This allows domain-specific logic to control aspects of the update that cannot be automated without intimate knowledge of your system.
Migration scripts run in one of two slots: before or after the template is updated.
The typical use of a before migration script would be to fix data before making a structure change (i.e., the nullability change without a default mentioned above).
Most migration scripts will be in the after slot to update or fix data making use of the new schema, introduce new seed data, etc.
Additionally, there are two life-times a migration script may have, run once or always. If a script
has its file name appended with [ALWAYS] it will run on every execution of the update
process, otherwise, it will be noted in the CompletedMigrationScripts table never
to be run again.