Runtime tools : Core components : Externalizers : Concepts : Runtime definition updates : How reset works in the typed data externalizer
  
How reset works in the typed data externalizer
The typed data externalizer differs from other externalizers because it does not maintain the list of tags stored during the initialization process. Therefore, it does not use tag instances to create the type instances when required. Instead, it keeps a list of type instances (which it creates from the tags read during initialization) and uses the list to instantiate the typed data element from a type. For this reason, the reset process for the type externalizer differs slightly from the other externalizers.
When an application requests a change to a type definition in the type externalizer, the type externalizer goes to the type instance and modifies it according to the new definition. Once the externalizer has modified the definition, whenever the externalizer instantiates a typed data element from that type, it uses the new type definition.
Note Type instances created before reset process are not aware of the changes.
The reset process modifies a type definition instead of replacing it. The reset process does this so that it can automatically update other types with property descriptors pointing to the modified type provided the descriptors do not override anything in the referred type. The toolkit allows this because these descriptors maintain the same type instance. If the property descriptors do have any extra definition to override, the reset process does not automatically update the default descriptor for that type with the new type definition.
If the modifications to a type includes adding references to other types, the reset process recursively resolves these references. If these references point to new type definitions, they must also be in the file or the reset process throws an exception.
Removing a type definition removes all the information that the instance contained but it does not remove the type instance itself. This has the following impact:
Future readObject calls for the empty type are not be able to instantiate a data element for that type. In this case, the method throws an exception.
Types that contain references to the removed type keep the reference but the reference points to the empty type. Future readObject calls for these types instantiate typed data elements according to the empty referenced types.
The type externalizer maintains the ID of the removed type so that no other new type can be defined using the same ID.
Go up to
Runtime definition updates