Current and Non-current Versions - Teradata Meta Data Services

Teradata Meta Data Services Programmer Guide

Teradata Meta Data Services
Release Number
English (United States)
Last Update
Product Category
Teradata Tools and Utilities

Current and Non-current Versions

By default, an application will only see the latest or highest-numbered version of an object. That version is termed the 'current' version. All other versions of the object will be considered non-current and will require special APIs to be viewed.

As an example of why it is necessary for the existing APIs to always use only the current version of objects, suppose you are executing two copies of the same program which continually reads and updates the property values for an object. In a non-versioned repository, it is sufficient to identify an object by its internal or global object ID, neither of which changes throughout the life of the object. The application knows that it can always read the current values for an object using the same object ID value regardless of how many times the object has been updated through WriteObject. Thus, for the two copies of the application, each copy knows that it is always seeing the latest values for an object's properties if it only knows the object ID returned by the first ReadObject for the object.

No changes to the application should be necessary for it to function correctly in a data versioning environment; consequently, the application should always be assured of working with the latest, current property values of an object without needing to know the object ID of the object's latest version. The object ID created when the object was created should be sufficient throughout the life of the application to get the latest property values through ReadObject and to update the latest property values through WriteObject. When data versioning is active, there is no guarantee that the object ID returned by ReadObject is still the object ID of the latest version. In between calling ReadObject and WriteObject, another application could have changed the object's values and created a new version. Consequently, to stipulate that an application always know the identity of the latest version of an object is unrealistic and unenforceable, thus all APIs that work with the current property values must always disregard the version represented by the object's internal object ID and instead determine the correct object ID.