Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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
        languagesql
        firstline1
        titlecustomer_billing_SEPT.sql
        linenumberstrue
        collapsetrue
        --------------------------------------------------------
        --  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:

...

  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 colulmncolumn. 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.

...

  1. 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.


Filter by label (Content by label)
showLabelsfalse
max5
spacescom.atlassian.confluence.content.render.xhtml.model.resource.identifiers.SpaceResourceIdentifier@1ff1d7
showSpacefalse
sortmodified
reversetrue
typepage
cqllabel in ( "changes" , "changeset" , "script" , "abandon" ) and type = "page" and space = "DDKB"
labelsabandon changes changeset script

...