| Table of Contents |
|---|
This guide is applicable when
- When your database changes do not deploy to all environments in the pipeline (or alternately, a few changes deploy to some environments while other change deploy to all environments)
- When developers need to specify labels at the time of commit or check in
- When you need to repackage your script which was previously packaged
Overview
The "metadata.properties" file can be a powerful tool when packaging database changes.
You can automatically assign labels and contexts to generated change sets by using ‘metadata.properties’ files that contain label and context specifications.
When a "metadata.properties" file is discovered during packaging in SCM mode, the Deployment Packager will add the labels and contexts defined in the properties file to all change sets produced by scripts checked into that directory. Labels and contexts assigned in this way are also hierarchical. The Deployment Packager will also associate labels and contexts with change sets generated by scripts processed in sub-directories of the directory where the metadata.properties file resides. To assign different labels and contexts to changes produced by scripts in these subdirectories, simply create a new "metadata.properties" file in the appropriate subdirectory. The labels and contexts will overwrite the values set by any metadata.properties file in ancestor directories.
The "metadata.properties" file also allow for files to be repackaged. For use cases when a particular script has already been packaged, and developers would like to fix the script and push it into SCM again without renaming the file name, the “allowRepackaging=true” will let Deployment Packager know to ignore the earlier version of this file and begin repackage the file. Note: The new script needs to account for what was already deploy by the older script. For example, the new script would need to “drop table” if it is creating the table which was previously created by the older script.
metadata.properties file
...
Property
...
Values
...
Description
...
labels
...
...
One or more labels that identify this set of changes so they can be easily identified and deployed as a group
...
contexts
...
...
Identifier to tie a set of changes to specific environments.
...
allowRepackaging
...
true or false
...
Since Datical DB v4.21, this property controls whether you can reuse a filename. The default value is false.
...
archive
...
true or false
...
Since Datical DB v4.21, this property controls whether files in the data_dml directory get copied to the archive directory. The default value is true.
...
schemaName
...
...
Since Datical DB v4.23, any scripts packaged will use this schema name when one is not specified for objects in the sql script.
...
| language | bash |
|---|---|
| firstline | 1 |
| title | metadata.properties |
| linenumbers | true |
...
| Include Page | ||||
|---|---|---|---|---|
|
Examples:
Let us work with an example. Assume that this is the directory structure within your sql_code directory:
...