Liquibase Enterprise was formerly known as Datical DB.
Packaging from a Manifest File
This functionality is maintained for backward compatibility with older methodologies.
The current recommended methodology for introducing database changes is to check SQL scripts into a source control repository and then package them into changesets.
You can create a manifest file to specify a set of SQL scripts to be packaged.
The manifest file specifies information for packaging:
location of scripts to be processed
metadata associated with these scripts
order of processing
When using a manifest mode, a deployPackager.properties file is required. It provides the location to use for database backups, databaseBackupRestoreLocation.
Metadata Definitions
Field Name | Field Description |
author | Name of the person who authored the SQL scripts |
comment | Any relevant comments related to this group of SQL scripts |
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. |
SQL File Definitions
Field Name | Field Description |
type | Type of file being processed – sqlfile, sqlplus, function, package, packagebody, procedure, data_dml, ddl |
filename | SQL file used for deploy. Use an absolute path or a relative path plus an sqlScmPath setting. |
rollbackFile | SQL file used for rollback. Use an absolute path or a relative path plus an sqlScmPath setting. |
Using Relative Paths
You can use a relative path for filename and rollbackFile if you also provide a value for sqlScmPath in deployPackager.properties. The filename used is constructed from the two values.
Example: The following example shows how to set sqlScmPath and use a relative path in filename.
SQL files location -
C:/Users/jsmith/datical/project/sql_code/proceduresqlScmPath -
C:/Users/jsmith/datical/project/sql_code/filename -
procedure/0001_P_POSTS_HAS_COMMENTS_NUM.sql
Portability
Using relative paths supports manifest file portability. When set up to use relative paths, the same manifest file could be used on multiple systems.
Systems of the same type
Systems of different types (Windows and Linux, for example)
In order to make a manifest file portable, you need to do the following:
Assure that the same relative path can work (compare the environments on the systems you plan to use)
Set the sqlScmPath value appropriately on each system.
Example of Portability
The path is two directories deeper on the Windows system.
| Local absolute path to SQL file | Relative Path in Manifest File | sqlScmPath value |
|---|---|---|---|
System A |
|
|
|
System B |
|
|
|
Generating the Manifest File
The Datical DB GUI provides a wizard for authoring manifest files. The files can also be authored manually in a text editor.
Example Manifest File
The following manifest file specifies the following changes to package:
DDL script, no rollback file
Procedure (stored logic), with a rollback file
[
{"author": "Smith, John"},
{"comment": "Sprint 21 Release"},
{"labels": "0351051"},
{"contexts": ""},
{"sqlfile":
{
"sqltype": "ddl",
"deployfile": "C:/Users/jsmith/datical/Blog_Import/sql_code/ddl/0001_create_table-review.sql",
"rollbackfile": ""
}
},
{"sqlfile":
{
"sqltype": "procedure",
"deployfile":
"C:/Users/jsmith/datical/Blog_Import/sql_code/procedure/0001_P_POSTS_HAS_COMMENTS_NUM.sql",
"rollbackfile":
"C:/Users/jsmith/datical/Blog_Import/sql_code/procedure/0001_P_POSTS_HAS_COMMENTS_NUM-rollback.sql"
}
}
]