Workspace  6.13.4
Understanding Update Barrier

Basic Usage

The purpose of this operation is to allow a particular branch of a workflow to be executed once and only when the user specifically triggers an update. Normally, a push button widget is attached to the Trigger input of the operation. When the button is pushed, only then will the Value input be brought up to date, have its date cloned and that cloned data stored in the Value output. Thereafter, any time the output data is needed, the cloned data is supplied, even if the Value input becomes not up to date. Only when the user presses the button that invalidates the Trigger input again will the Value input be brought up to date once more.

An important feature of this operation is that the first time the output is requested, the Value input is not brought up to date. Instead, the default value for the data type will be supplied at the output. This default value will continue to be supplied until the Trigger input is invalidated as described above.

The UpdateBarrier operation can be thought of as a "one-shot" trigger. It gives the user the ability to have a part of their workflow execute only once and only when they specifically ask for it to be executed. Note that normal workspace execution rules apply in the workflow connected to the Value input, however, meaning that if the workflow branch is brought up to date once and nothing is ever changed within that branch after that, then triggering the Trigger input will not cause the branch to re-execute.

Example

updatebarrier_example1.png
Stage 1

In this highly contrived example the Variable operation has an output data type of QString. The unnamed output of the Variable is connected to the Value input of the UpdateBarrier. The Value output of the UpdateBarrier is connected to a QLineEdit - shown docked on the right column of the screen. The Trigger input of the UpdateBarrier is connected to a QPushButton - shown docked on the right column of the screen.

Now, if you execute this workspace you may expect the Variable's value of "Hello Workspace" to be displayed in the QLineEdit widget attached to the UpdateBarrier (again, shown as Update Barrier –> Value in the right column). However when you do execute the Workspace only an empty string shown in the QLineEdit widget and the Variable's status bar does not go green.

updatebarrier_example2.png
Stage 2

While the Workspace is executing you can then click on the QPushPin connected to the UpdateBarrier (again, shown as Update Barrier –> Trigger). Now we see the value of "Hello Worldspace!" in the QLineEdit.

updatebarrier_example3.png
Stage 3

Similarities With CacheData

There is some similarity between the UpdateBarrier and CacheData operations. Both clone their main input and provide the copy at their main output. The CacheData operation can store multiple copies of the input and provide one of these cached copies based on some key, whereas UpdateBarrier only ever caches one value. One other important difference between the two is that CacheData will always execute at least once when its output is requested, whereas UpdateBarrier will not execute until its Trigger input allows it. This last point is important, since it means that when the user first loads a workspace containing an UpdateBarrier operation, the workflow branch connected to the main input of that operation still won't execute until the user triggers it. If the UpdateBarrier was replaced with a CacheData operation, then the first update of the operation would also update the branch without user intervention.

See Also
Polymorphic Operations, CacheData