Databases Reference
In-Depth Information
part of the composite and hence are not versioned with it. Redeployment of the UI
portion of a human workflow will overwrite the previous version and therefore may
break deployed versions of composites using them, unless the name of the human
workflow UI artifacts are changed when they are redeployed.
Revisions may be thought of as major versions. It is also possible to specify
milestones, which are sub-versions. This is done by appending a '-' to the
version, as in Calculator 1.1-test6. The name of the milestone must start with
an alphabetic character.
Version numbers can be used to keep distinct versions of the code separate in the
server. Deployment of a new revision of a composite does not impact the execution
of existing composite instances. Composite instances started with a particular
revision of a composite will continue to execute on that revision.
If a revision is undeployed, then any instances associated with that revision will stop
executing and will be marked as stale. This means that the data cannot be accessed
because the metadata of the composite definition is no longer available to help
interpret the composite instance data.
The default revision
There is a default revision associated with each composite name. When invoking
a composite, it is possible to specify a revision number, in which case, that exact
revision will be invoked. If no revision number is specified, then the default
revision, which is in force at the time of invocation, will be used.
The default revision can be used to help manage migration between revisions.
Imagine that we wish to deploy Calculator 1.1 alongside the currently deployed
Calculator 1.0. We are concerned that we haven't tested Calculator 1.1 with real
customers, so we would like to make it available as part of a beta program before
making it our default composite revision. In this case, we can deploy Calculator
1.1, but leave Calculator 1.0 as the default revision. Users invoking the composite
without a specific revision number will continue to invoke Calculator 1.0, but
beta customers can be pointed at the specific 1.1 revision. When we are satisfied
that Calculator 1.1 is a good revision, we can make it the default revision.
Now all customers who do not specify a revision number will create instances
of Calculator 1.1. Existing composite instances of Calculator 1.0 will continue to
execute to completion.
