SchemaSmith Enterprise Documentation

Define Your Database With Templates

A template is a metadata representation of a database.

Template JSON

Overview

A template is a metadata representation of a database. Conceptually, in object-oriented terms, a template is a class and a database is an instance. A template defines what a database should look like.

The Test Product has two templates defined for two different database definitions

the main template


{
    "Name": "Main",
    "DatabaseIdentificationScript": "SELECT [name] FROM master.dbo.sysdatabases WHERE [name] = '{{MainDB}}'",
    "VersionStampScript": "PRINT '{{ReleaseVersion}}'",
    "ScriptTokens": {
        "TestTableData": "<*File*>Tables/dbo.TestTable.data",
        "TemplateQueryToken": "<*Query*>SELECT 'true'"
    },
    "ScriptFolders": [
        { "FolderPath" : "MigrationScripts/Before", "QuenchSlot" : "Before" },
        { "FolderPath" : "Schemas", "QuenchSlot" : "Objects" },
        { "FolderPath" : "DataTypes", "QuenchSlot" : "Objects" },
        { "FolderPath" : "FullTextCatalogs", "QuenchSlot" : "Objects" },
        { "FolderPath" : "FullTextStopLists", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Functions", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Views", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Procedures", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Triggers", "QuenchSlot" : "AfterTablesObjects" },
        { "FolderPath" : "MigrationScripts/After", "QuenchSlot" : "After" }
    ]
}
                            

the secondary template


{
    "Name": "Secondary",
    "DatabaseIdentificationScript": "SELECT [name] FROM master.dbo.sysdatabases WHERE [name] = '{{SecondaryDB}}'",
    "VersionStampScript": "PRINT '{{ReleaseVersion}}'",
    "ScriptFolders": [
        { "FolderPath" : "MigrationScripts/Before", "QuenchSlot" : "Before" },
        { "FolderPath" : "Schemas", "QuenchSlot" : "Objects" },
        { "FolderPath" : "DataTypes", "QuenchSlot" : "Objects" },
        { "FolderPath" : "FullTextCatalogs", "QuenchSlot" : "Objects" },
        { "FolderPath" : "FullTextStopLists", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Functions", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Views", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Procedures", "QuenchSlot" : "Objects" },
        { "FolderPath" : "Triggers", "QuenchSlot" : "AfterTablesObjects" },
        { "FolderPath" : "MigrationScripts/After", "QuenchSlot" : "After" }
    ]
}
                            

With the proper use of templates, you can enable some powerful patterns like Multi-Tenant Database Registry.

Properties

Setting Value
NameThe name of the template is referenced by the TemplateOrder in the Product definition.
DatabaseIdentificationScriptA result set containing the names of every database that is of this type.
VersionStampScriptThis script is run last when updating a database of this type. Whatever is in this script block will be executed as a non-query (ie, like an insert/update script).
UpdateFillFactorWhether index fill factors should be updated within this template. Defaults to true.
IndexOnlyTableQuenchesSupport for index only table quenches.
BaselineValidationScriptOptional script to ensure that the current state of the database being updated is the expected version. It can be any sql needed to validate the version as long as the result is a scalar true or false result (BIT). This can help prevent accidentally applying an old version and creating an outage.
ScriptFoldersThe configurable folder list for the template level script folders.
ScriptTokensYou can define as many script tokens as you require. In the example above, you can see the TestTableData script token is being used to capture the content of a json file which can then be part of a script to populate or update seed data.
ServerToQuenchPrimary, Secondary or Both just like the product folder definition.

Index Only Table Quenches

This option is for use cases such as:
  • Supporting products that use transactional replication and need to have different indexes in the replica than in the publisher.
  • Maintaining indexes on a self-hosted 3rd party database.

For these use cases, you can define your tables with just the schema, name and indexes properties.

This option can be defined in the template.json like:


{
    "IndexOnlyTableQuenches": true
}
                

The default is false.

A table using this would be defined like:


{
    "Schema": "[dbo]",
    "Name": "[MyTable]",
    "Indexes": [
        {
            "Name": "[MyClusteredIndex]",
            "Clustered": true,
            "IndexColumns": "[ID]"
        }
    ]
}
                

When this table is quenched, only the indexes will be maintained and the table structure is being maintained through the article setup or some other means.

Additional Resources