SchemaSmith Documentation
AppSettings - PostgreSQL (Enterprise)
Configure defaults, paths, and connections for repeatable Postgres automation.
Configure defaults, paths, and connections for repeatable Postgres automation.
appsettings.json centralizes runtime configuration for SchemaQuench on PostgreSQL.
For the shared configuration loading order (file, environment variables, CLI switches) and
the SmithySettings_ environment variable prefix, see
Configuration Loading and
Environment Variables.
PostgreSQL Enterprise shares the same appsettings keys as other Enterprise platforms. This page lists the available settings and PostgreSQL-specific notes.
| 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. This can be a folder or a zip file containing the package contents. |
| Target:Server | The server to connect to. |
| Target:User | The sql user to authenticate as. |
| Target:Password | The sql user password. |
| WhatIfONLY | Defaults to 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 been applied. |
| MaxThreads | Defaults to 10 (max of 20 allowed). The number of threaded updates that happen simultaneously for each template being quenched. |
| DropTablesRemovedFromProduct | Default true. Allows for updating only a subset of tables in a patch scenario, without removing tables not included in the package. |
| UpdateTables | Default true. Allows bypassing the table update completely. For data fix pipelines it is sometimes desirable to deploy via a user with write access but not enough privileges to modify tables or procedures. |
| KindleTheForge | Default true. Allows bypassing the forge kindling, again to allow for the use of limited access users in specific pipelines. This option assumes a release has been previously applied to the environment in the past to properly create the procedures and tables needed by the tool suite. |
| CheckpointDirectory | The directory where checkpoint files are written when using the --ResumeQuench flag. Defaults to the log directory if not specified. See Checkpointing for full documentation on checkpoint-based resume. |
| DeliverData | Default true. When set to false, skips the automatic Data Delivery step during quench. Useful for pipelines that only need schema updates without data synchronization. |
| RunScriptsTwice | Default false. Re-executes all user scripts a second time after the initial pass. Useful when scripts have circular dependencies that resolve across two passes. See Migration Scripts for details. |
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.
While our primary focus is on ensuring that each server and database is in a true and expected state after a release is deployed, we also recognize the need to sometimes perform limited scope changes whether specific data fixes or emergency patches between releases. We also recognize that it is preferable not to have to add additional tools processes for such actions.
To that end we have exposed several granular control properties in the settings file:
DropTablesRemovedFromProduct, UpdateTables, and KindleTheForge. These settings combined
with the content of the update package will determine which steps are taken by SchemaQuench.
For a patch or data fix you can include a limited set of folders to simplify the update
package though product and template files are still needed, along with the basic folder
structure. to ensure quenching only the correct servers and databases.