Use the metadata.properties file to specify behavior during packaging.
...
Property | Values | Description | ||||||||||||
| disablePropertySubstitution allowRepackaging | archive | true | false | true | false | Turns off interpretation of properties set in the changelog. See Setting Properties in the Project Changelog. | disableSqlParser | true | false |
| Note | ||||
|---|---|---|---|---|
| ||||
When using the DATA_DML packaging method, the SQL Parser is disabled by default for DML with versions 7.6 and higher. |
labels
labelName[,labelName...]
One or more labels that identify this set of changes so they can be easily identified and deployed as a group. Multiple values must be separated by commas. No expressions are allowed.
contexts
contextName[,contextName...]
One or more context names to associate a changes with specified environments. Multiple values must be separated by commas. Expressions are allowed.
allowRepackaging
true | false
Deprecated starting with Datical DB v4.37. Use rerunnable instead.
Starting with Datical DB v4.21, this property controls whether you can reuse a filename. The default value is false.
Deprecated starting with Datical DB v4.37. Use rerunnable instead.
Starting with Datical DB v4.21, this property controls whether you can reuse a filename. The default value is false.
archive
Deprecated starting with Datical DB v4.37. Use rerunnable instead.
Starting with 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.
contexts
Overrides the project option enableSqlParser=true. There is no effect if the project-level setting is enableSqlParser=false. This property can be used in metadata.properties for folders that use packaging method DIRECT or SQLFILE. See Using SQL Parser.
| Note | ||||
|---|---|---|---|---|
| ||||
When using the DATA_DML packaging method, the SQL Parser is disabled by default for DML with versions 7.6 and higher. |
When enableRollbackOnError=true, Liquibase adds WHENEVER SQLERROR EXIT FAILURE ROLLBACK; into native tools which rolls back all of the possible rollback changes in case there is a failure. This prevents scripts from partially deploying.
When enableRollbackOnError=false, Liquibase adds WHENEVER SQLERROR EXIT SQL.SQLCODE; into native tools. This indicates Liquibase will not rollback if an error occurs which allows failure scripts to still be partially committed.
You may specify this property in the GUI or in the CLI during the deploy packager operation.
| Info |
|---|
| sqlPlus only: enableRollbackOnError is set to true by default. EdbPlus and ClpPlus only: enableRollbackOnError is set to false by default. |
labels
labelName[,labelName...]
One or more labels that identify this set of changes so they can be easily identified and deployed as a group. Multiple values must be separated by commas. No expressions are allowed.
Starting with Datical DB v4.37, use this property to classify SQL scripts as rerunnable (true) or non-rerunnable (false). Use it in place of the archive and allowRepackaging properties.
- Rerunnable scripts can be modified in place and repackaged. They stay in their original directory and are not archived.
- Non-rerunnable scripts can be packaged only once. During packaging the original scripts are moved from the original directory to an archive directory. They cannot be copied back and edited after packaging. To modify non-rerunnable scripts, use the create / replace workflow. See Developer Workflows: Managing Changesets During Development and Test.
Stored logic scripts are usually rerunnable as they perform CREATE OR REPLACE operations and can therefore be run multiple times and produce the same result (they are idempotent).
Set rerunnable to true or false.
- true - SQL code file is not archived. It can be repackaged.
- false - SQL code file is archived. It cannot be repackaged.
If not set, the value is assigned based on its type (the folder where it is placed in SCM):
- ddl - rerunnable=false
- ddl_direct - rerunnable=false
- data_dml - rerunnable=false
- sql_direct - rerunnable=false
- sql - rerunnable=false
- procedure - rerunnable=true
- package - rerunnable=true
- packagebody - rerunnable=true
- function - rerunnable=true
- trigger - rerunnable=true
- view - rerunnable=true
Important: although the use of archive and allowRepackaging are allowed, they are deprecated. In addition, the following combinations of settings now cause an error during packaging:
- archive=true and allowRepackaging=true
- archive=false and allowRepackaging=false
See also Flexible Folder Names. When you use flexible folder names it is important to specify rerunnable correctly.
During the packaging process, it verifies whether SQL scripts have corresponding -rollback or _rollback files for all scripts affected by the metadata.properties configuration. By default, this validation is set to false.
convert | ddl_direct | direct | data_dml | sqlfile | storedlogic | ssis | changelogStarting with Datical DB v5.0, specifies how to package the file, one of convert, ddl_direct, direct, data_dml, sqlfile, storedlogic, ssis. Packager further parses storedlogic files to determine their type, one of function, procedure, package, packagebody, trigger, view. See Flexible Folder Names.
Use the changelog value when packaging Liquibase changelogs. They are processed differently than SQL scripts. See Packaging Liquibase Changelogs and Flexible Folder Names.
schemaName
Schema name or comma-separated list of schema names.
Use either a literal value or a property. (If using a property, it must exist in the changelog, see Setting Properties in the Project Changelog).
If you use fully-qualified object names in SQL scripts, the schema names in the SQL scripts must match the schema names in the project. Packager returns an error if it encounters a schema reference that is not defined in the project.
For multi-database projects set, schemaName in the form <database>.<schema>. Starting in version 5.4, you can use a wildcard for the schema: <database>.*. This capability allows you to manage all SQL scripts for the database in a single folder.
| Note | ||||
|---|---|---|---|---|
| ||||
|
| Warning | ||
|---|---|---|
| ||
Do not use |
SQLWindows shared drive destination for support files that accompany an SSIS package file (.dtsx). (example: \\SSIS-TEST\SSIS_SHARED)
Specifies how to deploy existing versions of rerunnable changesets if multiple versions are available to deploy. Values are not case-sensitive.
- deployAll - (default) deploy all eligible versions in the order they appear in changelog.xml. This has been the strategy used historically (before versioning).
- deployLatest - deploy only the latest eligible version.
If versionStrategy is set to any other value, processing stops with an error.
A changeset is eligible to deploy if it meets criteria set in the deploy operation (label expression).
Specified only in the metadata.properties file at the top of the SQL code tree. That directory must be the one specifed by the sqlScmSQLBaseDirproperty in the deployPackager.properties file.
Provide a list of directories, in the order you want them packaged. Files from these directories are pulled to the front of the packaging order in front of any other folders in the packaging job. See Custom Packaging Order.
...