The TopLogic model and its data are versioned automatically. This means that information is not overwritten when changes are made - be it changes to the model or changes to application data. Instead, each change creates a new version. Old versions are retained and can be used for comparison or for revision security purposes.

Technical versioning (revisions)

Technically, each commit in the TopLogic database creates a new version (revision). The version is identified by a consecutive revision number. This revision number can be used to reconstruct every version of the system since its installation. However, only the current data status (with the special revision "Current") can be changed. All completed versions are unchangeable. A distinction is made between two different states of objects. There are current objects (from the current data status) and historical objects from a completed version. A transaction in the system changes the status of one or more current objects and records this change in a new version.

Normal views and search queries always operate in the current data status. To display a completed version, either a historical version of a current object in a specific revision must be searched for (see Object in a revision) or a so-called historical reference must be used to navigate "into the past".

Historical references

References are used to map relationships between objects. A normal reference has the historicization "Current". This means that the reference to a current object has one or more current objects as its target. If you navigate from a historical object (from a stable version) via a reference with "Current" historicization, the result is also historical objects from the same version as the source object. You can say that navigation via a current reference retains the timeline.

To be able to save references to a stable version, you need a reference with "Historical" historicization. Historical versions of objects can be saved in such a reference. Starting from a current object, you always receive a historical object from a stable version when navigating via a historical reference. Of course, the same also applies if you navigate a historical reference of a historical object. The result is then also a historical object but possibly from a different timeline than the original object. Navigation via historical references can therefore change the timeline.

References with historicization "Historic" have another special feature. If you save one or more other current objects in a historical reference of a current object, the version of these target objects is recorded in the commit of the transaction. If you navigate the same historical reference after the commit, you will receive historical versions of the target objects in the version created by the commit, starting from a current object. If you change their current variant in another transaction, this has no effect on the target objects of the historical reference. It can be said that saving current objects in historical references freezes their state when they are committed. A current reference (a reference to a current object) becomes a stable reference (a reference to an unchanging historical object) in the commit.

The last option for historicization is the "Mixed" flavour. Both historical and current objects can be saved in a reference with "Mixed" historicization. The values are retained here exactly as they were saved, so there is no stabilization of current references. If a current object is saved in a mixed reference, you will still receive a current reference after the commit. The same applies to a historical reference.

Technical versioning

Although every change to the system technically creates its own version, this usually has no technical significance. Normally, you want to record very specific versions in a system and give them a technical designation (such as a report completion, a release, etc.). However, technical versioning can also be used to reconstruct the status of one or more objects at a certain point in time (cf. revision at a point in time).

A technical versioning of a system state is usually achieved by saving a current object in a historical reference. The state of this object (and therefore of all objects linked to this object via current references) is recorded. As the reference in the commit is stabilized to a historical reference to the object at the time of the commit, this reference represents a functional version after the commit.

Switch off versioning

If versioning is not required in a system, it can be switched off either globally (for all types) or specifically for individual tables. See Deactivate versioning globally or Deactivate versioning for table. With partial versioning, however, it must be noted that a versioned type cannot hold references to unversioned types. Otherwise, the status of a stable version could subsequently change if unversioned objects are deleted as a result. However, there are no restrictions for references to unversioned objects. They can contain either other unversioned or versioned objects.

See also Data versioning.