Liquibase Enterprise was formerly known as Datical DB.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Qualifying Object Names

  • Do not qualify objects with the database name as PostgreSQL connections represent one database at a time.

  • For a Single-Schema project, you don’t need to qualify object names with the schema name. If they are not qualified, Datical DB uses the default schema if it is specified.

  • For a Multi-Schema project, you must qualify object names with the schema name so they get deployed to the correct schema during packaging.

  • You can use the schemaName attribute in the metadata.properties file to specify the default schema. See Using the metadata.properties file.

PostgreSQL SCM Packaging Patterns

Datical DB packages non-transient files differently from transient files. Place scripts for PostgreSQL objects in packaging folders as follows:

Non-transient—In-place editing, packaging, and no archiving of database changes so they can be managed similar to application code. This applies to the following object types:

  • Procedures (when scripts are placed in the procedure folder)

  • Views (when scripts are placed in the view folder)

  • Triggers (when scripts are placed in the trigger folder)

Transient—Database changes are archived after packaging (all other folders).

PostgreSQL packaging doesn't support ssis/ssis_project, package, packagebody, and sqlplus folders.

Packager requires that stored logic scripts (procedure, view, trigger) have only one object or statement per file with nothing preceding or following the object definition. No additional statements.

Objects and Packaging Folders

Use the specified folder for listed PostgreSQL database operations. 

Operation and Object Type

Packaging Folders (fixed folders)

Package Methods (flexible folders)

Archived

Notes

CREATE/ALTER/DROP DATABASE LINK

sql_direct

direct

Yes

CREATE/ALTER/DROP FUNCTION

sql_direct

direct

Yes

CREATE/ALTER/DROP INDEX

ddl, ddl_directsql_direct,

convert, ddl_direct, direct

Yes

CREATE/ALTER/DROP PROCEDURE

procedure

storedlogic

No

CREATE/ALTER/DROP QUEUE

sql_direct

direct

Yes

CREATE/ALTER/DROP SEQUENCE

ddl, ddl_directsql_direct

convert, ddl_direct, direct

Yes

CREATE/ALTER/DROP SYNONYM

ddlddl_direct, sql_direct

convert, ddl_direct, direct

Yes

For ALTER and CREATE OR REPLACE synonym use ddl_direct or sql_direct/direct. (Do not use ddl/convert with ALTER and CREATE OR REPLACE synonym.)

CREATE/ALTER/DROP TABLE

ddlddl_direct, sql_direct

convert, ddl_direct, direct

Yes

For PARTITIONED TABLE changes, use sql_direct folder

CREATE/ALTER/DROP TRIGGER

trigger

storedlogic

No

CREATE/ALTER/DROP TYPE

sql_direct

direct

Yes

CREATE/ALTER/DROP VIEW

view

storedlogic

No

CREATE/ALTER/DROP VIEW INDEX

ddlddl_direct, sql_direct

convert, ddl_direct, direct

Yes

RENAME <DB_OBJECT>

sql_direct

direct

Yes

Operation

Packaging Folder (fixed folders)

Package Method (flexible folders)

Archived

INSERT, UPDATE, DELETE, SELECT

data_dml

data_dml

Yes

GRANT, REVOKE

sql_direct

direct

Yes

Error Handling

Do not put error-handling statements in the SQL scripts.

Datical DB has its own error-handling that wraps SQL scripts. Specifying error-handling within the statements is not necessary.

Deployment Packager fails with an error if it encounters statements before an object definition.

For more information about packaging workflows, packaging methods, and folders for specific types of changes, see the following pages:

  • No labels