SchemaSmith Enterprise 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.
Product level migration scripts run in one of two slots: Before or
After the product is updated. When a product level script folder is defined, it
allows indicating if the scripts within the folder should be run on the Primary,
Secondary, or Both server roles.
These scripts would typically be used to add things like logins or jobs, manage permissions, or validate server configurations.
By default, product level scripts run in the context of the master database.
Product level scripts always run on every execution. There is no table for tracking past usage.
Template level migration scripts run in one of tree slots: Before, After Tables
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 template level 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.