Migration Scripts - Schema-Smith/SchemaSmithEnterpriseDemos GitHub Wiki

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 prior to 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 can not be automated without intimate knowledge of your system.

Template level migration scripts

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 prior to making a structure change (ie, 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.

Product level migration scripts

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 the product level scripts run in the context of the master database.

[!IMPORTANT] Product level script always run on every execution. There is no table for tracking past usage.