Runtime components : Core components : Externalizers : Concepts : Runtime definition updates : How the reset process resolves references
  
How the reset process resolves references
During the initialization of the toolkit, the externalizers resolved tag linking references. This modifies the tag structure in memory so that all the reference tags pointing to the same entity point to the same tag definition instance. To dynamically update the tag structure in memory, the reset process does the following:
1 The reset process creates a temporary externalizer. The temporary externalizer performs tag linking in the same way that the other externalizers perform tag linking during the initialization of the toolkit. The difference is that the temporary externalizer uses the definition files that contain the updated definitions. In this way, the reset process creates a parallel tag structure and its reference tag definitions point to the new tag definition instances created in the new temporary tag structure.
2 The reset process compares the tag structure in the temporary externalizer with the tag structure in the original externalizer to determine which tag definitions in the externalizer it needs to modify.
3 The reset process modifies all the attributes of the original tag instance with the attributes of the new tag instance definition. In this way, all the references to the modified entity in the original externalizer see the modification.
For example, the definitions for an entity called B have been updated in the definition file. In the following table, the "Before the update" column shows the file and tag structure in memory before the update was made. The "After the update" column shows the changes in the file and the tag structure in the temporary externalizer. The numbers in parentheses are the instance numbers of the tags.
Resetting the B entity
 
 
Before the update
After the update
Definition file
<kColl id="A">
<refData refId="B"/>
</kColl>
<field id="B"/>
<kColl id="A">
<refData refId="B"/>
</kColl>
<kColl id="B">
<refData refId="C"/>
<refData refId="D"/>
</kColl>
<field id="C" />
<field id="D" />
Tag structure
Tag A(1)
subtag of A(2)
Tag B(2)
Tag A(3)
subtag of A(4)
Tag B(4)
subtag of B(5)
subtag of B(6)
Tag C(5)
Tag D(6)
The tag structure in the original externalizer after performing the reset process on the B definition is:
Tag A(1)
subtag of A(2)
Tag B(2)
subtag of B(5)
subtag of B(6)
There is a limitation to the reset process as the following example demonstrates:
Resetting the B and C entities
 
 
Before the update
After the update
Definition file
<kColl id="A">
<refData refId="C"/>
</kColl>
<kColl id="B">
<refData refId="C"/>
<refData refId="D"/>
</kColl>
<field id="C"/>
<field id="D"/>
<kColl id="A">
<refData refId="C"/>
</kColl>
<kColl id="B">
<refData refId="C"/>
<refData refId="D"/>
<refData refId="E"/>
</kColl>
<field id="C"/>
<field id="D"/>
<field id="E"/>
Tag structure
Tag A(1)
subtag of A(3)
Tag B(2)
subtag of B(3)
subtag of B(4)
Tag C(3)
Tag D(4)
Tag A(5)
subtag of A(7)
Tag B(6)
subtag of B(7)
subtag of B(8)
subtag of B(9)
Tag C(7)
Tag D(8)
Tag E(9)
The tag structure in the externalizer after performing the reset process on the B definition followed by doing the reset process on the C definition.
Tag A(1)
subtag of A(3)
Tag B(2)
subtag of B(7)
subtag of B(8)
subtag of B(9)
Tag C(3)
Tag D(4)
The reset process updates tag instance 3 but only propagates the change in entity A. The reset process does not propagate the change in entity B because the reset process has changed the instance number back to 3 and the entity B still points to tag instance number 7.
Go up to
Runtime definition updates