appSettings.json - Schema-Smith/SchemaSmithEnterpriseDemos GitHub Wiki
What can be configured
| Setting | Value |
|---|---|
| SchemaPackagePath | The path to the root of the product repository/package. SchemaQuench requires the repository to be placed in a location where the files can be loaded by the executable. The location will contain the Product.json and the folders for templates and other files. |
| Target:Server | The server to quench |
| Target:User | The sql user to authenticate as. Leave blank for windows authentication. |
| Target:Password | The sql user password. Leave blank for windows authentication. |
| WhatIfONLY | Default false. When true a what if run is done that shows the changes that are detected and what would be applied if allowed to. This run may not be accurate if there are dependencies upon other actions that have not be applied. |
| Target:SecondaryServers | The secondary server(s) to quench. The login information must be identical to the primary. Secondary servers are for supporting the other, non-primary servers in a clustered setup. Can be a list if there are multiple servers setup in the cluster. |
| MaxThreads | Defaults to 10 (max of 20 allowed). The number of threaded updates that happen simultaneously for each template being quenched. |
After the appSettings file is loaded, environment variables are applied. The above settings can be set via setx commands or standard windows environment variables using the prefix QuenchSettings_. You can even override various production configuration like for setting Script Tokens, see the docker-compose.yml for an example of this usage.
Threaded database updates
If a template defines multiple databases, each of those updates occur in a thread. This is defined in the configuration file in the option MaxThreads, the default is 10.
Secondary Server Support
Schema Quench supports clustered sql server installations. There are at least two cases where you may need to quench parts of your configuration against a secondary set of servers:
- Logins
- Jobs
Secondary servers can be defined in the Product and configured for use in product and template script folders.
Additionally there is the ability to add the ServerToQuench in the template.json which can be Primary, Secondary or Both just like the product folder definition. A use case for this would be to apply objects to master on both servers or any database not part of the availability group.