How To: Abandon a Single Changeset from a Script

Owned by Former user (Deleted)
Last updated: Nov 22, 2021 by Former user (Deleted)
4 min read


Instead of abandoning all changesets from a single script, there is desire to abandon just one changeset. 

For example: A script got packaged which generated 5 different changesets. Now, we only want to abandon one of those 5 changesets.

Another documentation talks about how to abandon all changesets resulting from a single script (How To: Abandon changes). But this would abandon all 5 changesets, per our example. 

Considerations

Several considerations must be taken into account. 

  1. Only DDL scripts (scripts committed into the "ddl" directory when using the default "convert" packaging method) will generate multiple changesets.
    • This means that a unique changeset will be generated for each object that the DDL script operates on. 
    • Here is an example: a script created two changesets because it contains SQL code for creating two different tables:

      • customer_billing_SEPT.sql 
        --------------------------------------------------------
--  DDL for Tables: 
--					customer_billing_address
--					customer_billing_details
--------------------------------------------------------

CREATE TABLE "PPADM"."customer_billing_address" 
   (	"ID" NUMBER(*,0), 
	"FIRST_NAME" VARCHAR2(50 BYTE), 
	"MIDDLE_NAME" VARCHAR2(50 BYTE), 
	"LAST_NAME" VARCHAR2(50 BYTE)
   ) SEGMENT CREATION DEFERRED 
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
 NOCOMPRESS LOGGING
  TABLESPACE "PPDEFAULT" ;
REM INSERTING into PPADM.customer_billing_address
SET DEFINE OFF;


CREATE TABLE "PPADM"."customer_billing_details" 
   (	"ID" NUMBER(*,0), 
	"FIRST_NAME" VARCHAR2(50 BYTE), 
	"MIDDLE_NAME" VARCHAR2(50 BYTE), 
	"LAST_NAME" VARCHAR2(50 BYTE)
   ) SEGMENT CREATION DEFERRED 
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
 NOCOMPRESS LOGGING
  TABLESPACE "PPDEFAULT" ;
REM INSERTING into PPADM.customer_billing_details
SET DEFINE OFF;
  2. Scripts committed into any other directory (data_dml, ddl_direct, function, package, packagebody, procedure, sql, sql_direct) will result in only one changeset for that script.
    • Here is how a changeset would look like which generated from a script committed into "data_dml" directory:

Primary Process

It is recommended to ALWAYS abandon the ENTIRE script - i.e., all changesets generated from that script - instead of surgically abandoning only a one changeset. 

Since the goal is to automate database changes, we need a process in place which is self-correcting. 

Even though it is desirable to abandon a single changeset, there are many reasons not to do this. 

Pros:

  1. The script has already been packaged in REF database. This means that all resulting changesets have been deployed TOGETHER. 
    1. Abandoning a single changeset could create a PROBLEM when deploying later in the pipeline. The new combination of changesets (all changesets minus the abandoned changeset) have never been deployed in that configuration and therefore there is a risk of dependencies resulting in deploy failures.
  2. Preferred path requires that you abandon the entire script by bringing a "fix" and follow the process described in How To: Abandon changes. 
  3. Even though this feels unnecessary, we are adhering to a consistent process designed for change abandonment.

Cons:

  1. It is cumbersome to create and commit a fix script (following the process described in How To: Abandon changes)

Alternate Process

Abandoning a single changeset from a DDL script which generated multiple changesets can only be done using Datical GUI. As such, it should be noted that this would be a manual task and could impact release automation platform if not done correctly. Therefore, this path should be taken very rarely and with great caution.

You will need to make sure that your Datical project is connected to your SCM and that you are working on the latest version of your project.

  1. In Datical GUI, get the latest version of the Datical project from SCM. E.g., "git pull"
  2. Click on "Fully Deployed" link or "???" link on any of the REF databases in your project. This will take you to Deployed, Undeployed, Ignored view.
  3. Use the filter field at the top to filter out your changesets based on the script name and then click "Filter by label"
  4. Select the changeset you want to abandon and click "Add Label"
  5. Type "abandoned" in the Ad Hoc Labels to Add field and then click "Next"
  6. Notice that the new label now appears in the Labels After column. Click "Finish"
  7. Notice that this changeset now has the new "abandoned" label
  8. VERY IMPORTANT: Commit and push your Datical project back into SCM.
    1. Adding labels (or removing labels) updates the changelog.xml file in your Datical project which needs to stay updated in your SCM. For example, "git commit ..." followed by "git push".
  9. Now that the "abandoned" label has been added, make sure to create a new artifact version. You will need to run a job in build automation tool to do this. For example, your Deployment Packager job may already be configured to publish your changes into a new artifact version. You can run the Packager job and even though there are no new scripts to package, the job will complete successfully and proceed to publish a new artifact version.
    1. When you use your deployment automation tool you will use your newly created versioned artifact to deploy database changes.




Copyright © Datical 2012-2020 - Proprietary and Confidential