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

Technical versioning (revisions)

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

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

Historical references

References are used to represent relationships between objects. A normal reference has the historization "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 the historization "Current", you will also receive historical objects from the same version as the source object as a result. It can be said that navigation via a current reference preserves the time line.

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

References with historicization "Historic" have another special feature. If one stores one or more other current objects in a historical reference of a current object, then the version of these target objects is fixed in the commit of the transaction. If one navigates the same historical reference after the commit, then one receives, starting from a current object, historical versions of the target objects in the version created by the commit. If one changes 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 access at commit. A current reference (a reference to a current object) becomes a stable reference (a reference to an immutable historical object) in the commit.

The last option left for historization is the flavor "Mixed". Both historical and current objects can be stored in a reference with historization "Mixed". The values are preserved here exactly as they were saved. so there is no stabilization current references. If a current object is stored in a mixed reference, you still get a current reference after the commit. The same applies to a historical reference.

Technical versioning

Each change at the system produces technically seen its own version, this has however as a rule technically no meaning. Normally one would like to hold very special versions in a system and give these a technical designation (like a report conclusion, a release, or the like). However, technical versioning can also be used to reconstruct the state of one or more objects at a certain point in time (cf. revision at a point in time).

A technical fixing of a system condition one reaches as a rule over the storage of a current object into a historical reference. Here the condition of this object (and thus all objects connected with this object over current references) is fixed. Since 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 necessary in a system, it can be switched off either globally (for all types) or specifically for individual tables. See Disable versioning globally or Disable versioning for table. With parcial versioning, however, it must be noted that a versioned type cannot hold references to unversioned types. Otherwise the state of a stable version could change afterwards if unversioned objects are subsequently deleted. However, there are no restrictions for references of unversioned objects. They can contain either other unversioned or versioned objects.