VocApp-Proposal/MultiStep

Creating Multi-step Change Proposals

Virtually all change proposals involve multiple revisions that are executed sequentially. This is not what is meant by a Multi-step Change Proposal in this context.

A Multi-step Change Proposal is:

a proposal that involves several revisions some of which cannot be defined with this tool until the earlier revision(s) have been applied to the database

This dependency does not exist for most compound proposals. One can define many "additive" revisions without encountering the problem. The problem here is not the execution of the revisions, because the database will have been updated by the earlier revisions, but rather is the difficulty of defining the later revisions with the tool.

Multi-step Illustration

Suppose you have reason to move a previously defined Coded Concept from one Value Set to its parent value set. The steps are easy to figure:

1. Remove the code from the first value set, and
2. Add it to the second value set.

The problem arises with defining these steps with the tool. It is easy enough to use the Remove Codes from a Value Set revision to accomplish the first step. However when you try to use the Add Codes to Value Set revision to accomplish the second step, the tool blocks you because it recognizes that the code is "already" a member of the parent because it is (still) a member of the child.

Solution 1: Create Two Change Proposals

The simplest way to address this problem is to:

1. Create a change proposal to accomplish step 1 above
2. Apply this first change proposal to the database, thus freeing the restriction
3. Create A second change proposal to do Step 2
4. Apply the second change proposal to the database.

The challenge with this process is that you now have two change proposals to accomplish one task, and if you need to redo these, for example after a database restore, you will need to apply both change proposals in sequence.

Solution 2: Edit a Single Proposal in XML

The limitations cited above can be overcome by opening the two change proposals in an XML editor, and copying the "revisions" from the second file into the first file following the last of the "revisions" in the first file. Although it requires manual intervention, this method can be used to combine several proposal sets into one.

Solution 3: Create a Single Multi-step Proposal

This can be done by sequentially updating the data base as the process proceeds:

1. Create a change proposal to accomplish step 1 above
2. Apply this first change proposal to the database, thus freeing the restriction
3. Add the second revision to the change proposal created in Step 1
4. Restore the database
5. Apply the compound proposal to the database.

The last three steps can be repeated again to deal with serial revision dependencies. The advantage of this approach (and of the approach to edit the XML files) is that it assures that related changes are kept together and that they are executed together or not at all.

Tool Enhancement

Note that the tool might also be enhanced to flag the conflict noted in the example, but to allow the second step to be defined anyway. After all, the conflict will not arise when the proposal is executed as a set of serial revisions. This enhancement will be entered as a "feature request" in Gforge.