Page Comparison

...

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

...

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. 

...

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:

   • 
     

     • 

       Code Block
       language sql firstline 1 title customer_billing_SEPT.sql linenumbers true collapse true
       -------------------------------------------------------- -- 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:
   • 

Step-by-step guide

...

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.

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.
   1. Image Added
   2. Image Added
3. Use the filter field at the top to filter out your changesets based on the script name and then click "Filter by label"
   1. Image Added
4. Select the changeset you want to abandon and click "Add Label"
   1. Image Added
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"
   1. Image Added
7. Notice that this changeset now has the new "abandoned" label
   1. Image Added
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.

Related articles

...