Page Comparison

...

Examples of such cases are: Adding a new object, e.g., a new table, a new column or a new procedure, and this object is no longer needed. Since the addition of an object is not a concern for data loss, it is save safe to deploy such changes into the pipeline. These changes could be safely negated by another script. As a result, the final state of the database would not show any of those changes.

...

1. Commit a negating script. Since this script simply performs a "drop table" operation, this script can be committed into the "ddl" directory. 
   1. From naming convention perspective, you would want to name this script as something meaningful for users, e.g., "drop_international_billing_custom_table.sql". 
      1. Notice that this will not result in net data loss when both "create table" and "drop table" are deployed to a target environment respectively. 
2. Datical will package negating scripts into changesets.
   
   1. Note that the changeset will inhert inherit a label based on the script name. This could be useful later when reviewing status, forecast or deploy reports.
3. Because the negating script was packaged in a later commit relative to the initial script, Datical will deploy the negating script in the same order as the SCM commit.
   1. For example, when deploying changes to PROD environment, Datical will deploy all changesets from the originating script ("international_billing.sql"). This will also create the unwanted table in PROD. Datical will then proceed with deploying other changesets including the negating changeset which will remove the unwanted table "international_billing_custom" from PROD. 

...

We will assume that a script by the name of "international_customer_dependents.sql" was packaged from the "procedure" directory. This script contains code for a procedure "intl_cust_dep". Because the original script has been packaged already,  there exists a Datical changeset for this procedure. During testing, you realize that the procedure needs to be fixed. Steps below will guide you how to package a fix for this procedure.

1. Since scripts in the "procedure" directory do not get archived, the original faulty script is already exists in that directory.
2. The Developer will checkout the script from SCM 
3. Rework the script.
4. Commit the reworked script using the same file name and in the same directory where it was originally placed ("procedure").
5. Packager will detect a new commit in the "procedure" directory. As a result, a second changeset will be created for the same procedure.
6. Because the reworked script was packaged in a later commit relative to the original faulty script, Datical will deploy the reworked script in the same order as the SCM commit.
   1. For example, when deploy changes to PROD environment, Datical will deploy the first changeset for "intl_cust_dep" procedure. This will create the procedure in PROD with faulty code. Datical will then proceed with deploying other changesets including the reworked changeset which will update the procedure with new code.

...