Stashing

Previous Next

Understanding "stashing"

Stashing is the process of making a safe temporary copy of production data that is in danger of getting lost during upgrade. Before the upgrade, you stash the data. After the upgrade, you re-import it in a different form. Delivery Manager proposes a standard way of implementing "stashing", which is to export the data to an XML file in a pre-upgrade script (using INVOKE XML.EXPORT), then to change its name or form (or both) by applying an XSLT transformation, and then to re-import the data from XML in a post-upgrade script (using INVOKE XML.IMPORT):

DL_clip0021

This default implementation of "stashing", however, is not always ideal. There could be performance or storage penalties if the volume of the exported, duplicated data is very large. There are numerous alternatives. To prevent data export but still rename an ADDRESS column to a HOME_ADDRESS column, you could plan as a first step to add the new column, then have the RDBMS duplicate the data from the old to the new column, and then drop the old column. The drawback of such a procedure is that the Rules Engine is bypassed so that you need to validate data integrity after the fact.

Implementing "stashing"

Follow these steps to prepare stashing and reclaiming data on target machines during upgrade, using the default XML/XSL implementation :

1.In the Computers window (choose Define, Computers from the menu), specify what is the stash location on each computer of interest.
2.In a Pre-upgrade script, using the $$stash path variable to identify the stash location, include an XML.EXPORT statement that writes the data that you want to preserve to a stash file. The SQL will typically look like this:

INVOKE XML.EXPORT WITH 

SELECT     '$$stash\mystasheddata.xml' WriteOutputTo

,          query

 

For example, to preserve the entire contents of a table called MYPARAMETERS, the SQL will look like this:

INVOKE XML.EXPORT WITH 

SELECT   '$$stash\Parameters.xml' WriteOutputTo

,        *

FROM        MYPARAMETERS

 

3.Implement the transformation:

•Either by adding XSL to the XML.EXPORT statement, or

•By inserting an explicit INVOKE USXSL.APPLY2FILE statement in your Pre-upgrade or Post-upgrade script, in which case you can use the $$stash path variable in some or all of the (3) arguments.

4.In a Post-upgrade script, include an XML.IMPORT statement that picks up the transformed data after upgrade. The SQL will typically look like this:

INVOKE XML.IMPPORT WITH

SELECT     '$$stash\mytransformeddata.xml' 

 

For example, to pick up new Parameters, write:

INVOKE XML.EXPORT WITH 

SELECT   '$$stash\NewParameters.xml'

 

You are now ready to check the scripts, run the Release Scripts task, and distribute the result to target machines. On each target machine, stashing will execute correctly if the scripts are run in the order indicated by the sequence numbers in the filenames.

 

See Also

Tips for testing stashing