Das TopLogic-Modell und seine Daten werden automatisch versioniert. D.h. Informationen werden bei Änderung - seien es Änderungen am Modell oder Änderungen an Anwendungsdaten - nicht überschrieben. Stattdessen erzeugt jede Änderung eine neue Version. Alte Versionen bleiben erhalten und können zum Vergleich oder zu Zwecken der Revisionssicherheit herangezogen werden.

Technische Versionierung (Revisions)

Technisch erzeugt jedes Commit in der TopLogic-Datenbank eine neue Version (Revision). Die Version wird über eine fortlaufende Revisionsnummer identifiziert. Über diese Revisionsnummer kann jeder Stand des Systems seit seiner Installation rekonstruiert werden. Dabei ist aber nur der aktuelle Datenstand (mit der speziellen Revision "Current") veränderlich. Alle abgeschlossenen Versionen sind unveränderlich. Dafür werden zwei unterschiedliche Zustände von Objekte unterschieden. Es gibt aktuelle Objekte (aus dem aktuellen Datenstand) und historische Objekte aus einer abgeschlossenen Version. Eine Transaktion im System Ändert den Zustand von einem oder mehreren aktuellen Objekten und schreibt diese Änderung in einer neuen Version fest.

Normale Sichten und Suchanfragen operieren immer im aktuellen Datenstand. Um eine abgeschlossene Version anzuzeigen, muss entweder zu einem aktuellen Objekt eine historische Version in einer bestimmte Revision herausgesucht werden (vgl. Objekt in einer Revision) oder es muss über eine sog. historische Referenz "in die Vergangenheit" navigiert werden.

Historische Referenzen

Über Referenzen werden Beziehungen zwischen Objekten abgebildet. Eine normale Referenz hat die Historisierung "Aktuell". D.h. die Referenz an einem aktuellen Objekt hat als Ziel wiederum ein oder mehrere aktuelle Objekte. Navigiert man ausgehend von einem historischen Objekt (aus einer stabilen Version) über eine Referenz mit Historisierung "Aktuell", erhält man als Ergebnis ebenfall historische Objekte aus derselben Version wie das Ausgangsobjekt. Man kann sagen, die Navigation über eine aktuelle Referenz behält die Zeitschiene bei.

Um sich Referenzen auf eine stabile Version speichern zu können, benötigt man eine Referenz mit Historisierung "Historisch". In eine solche Refernz können historische Versionen von Objekten gespeichert werden. Ausgehend von einem aktuellen Objekt erhält man bei Navigation über eine historische Referenz also immer ein historisches Objekt aus einer stabilen Version. Dasselbe gilt natürlich auch wenn man eine historische Referenz eines historischen Objektes navigiert. Das Ergebnis ist dann ebenfalls ein historisches Objekt aber möglicherweise aus eine anderen Zeitschiene als das Ausgangsobjekt. Navigation über historische Referenzen kann also die Zeitschiene wechseln.

Referenzen mit Historisierung "Historisch" haben noch eine Besonderheit. Speichert man in eine historsiche Referen eines aktuellen Objektes ein oder mehrere andere aktuelle Objekte, so wird die Version dieser Zielobjekte im Commit der Transaktion festgeschrieben. Navigiert man dieselbe historische Referenz nach dem Commit, so erhält man ausgehend von einem aktuellen Objekt historische Versionen der Zielobjekte in der durch das Commit erstellten Version. Ändert man in einer weiteren Transaktion ihre aktuellen Variante, hat das keine Auswirkung auf die Zielobjekte der historischen Referenz. Man kann sagen, dass das Speichern von akutellen Objekten in historische Referenzen deren Zustand beim Commit einfriert. Aus einer aktuellen Referenz (einer Referenz auf ein aktuelles Objekt) wird im Commit eine stabile Referenz (eine Referenz auf ein unveränderliches historisches Objekt).

Als letzte Option für die Historisierung bleibt die Geschmacksrichtung "Gemischt". In eine Referenz mit Historisierung "Gemischt" können sowohl historische als auch aktuelle Objekte gespeichert werden. Die Werte bleiben hier exakt so erhalten, wie sie gespeichert wurden. es findet also keine Stabilisierung aktuelle Referenzen statt. Wird ein aktuelles Objekt in eine gemischte Referenz gespeichert, erhält man nach dem Commit immer noch eine aktuelle Referenz. Gleiches gilt für eine historische Referenz.

Fachliche Versionierung

Jede Änderung am System erzeugt zwar technisch gesehen eine eigene Version, diese hat aber i.d.R. fachlich keine Bedeutung. Normalerweise möchte man ganz spezielle Versionen in einem System festhalten und diesen eine fachliche Bezeichnung (wie einen Berichtsabschluss, ein Release, o.ä) geben. Die technische Versionierung kann aber auch dafür verwendet, werden, den Zustand eines oder mehrerer Objekte zu einem gewissen Zeitpunkt zu rekonstruieren (vgl. Revision zu einem Zeitpunkt).

Ein fachliches Festscheiben eines Systemzustandes erreicht man in der Regel über das Speichern eines aktuellen Objektes in eine historische Referenz. Hierbei wird der Zustand dieses Objektes (und damit aller mit diesem Objekt über aktuelle Referenzen verbundener Objekte) festgeschrieben. Da die Referenz im Commit zu einer historischen Referenz auf das Objekt zum Zeitpunkt des Commits stabilisert wird, repräsentiert diese Referenz nach dem Commit eine fachliche Version.

Versionierung abschalten

Wenn in einem System keine Versionierung notwendig ist, kann diese entweder global (für alle Typen) oder spezifisch für einzelne Tabellen abgeschaltet werden. Siehe hierzu Versionierung global abschalten oder Versionierung für Tabelle deaktivieren. Bei parzieller Versionierung muss aber beachtet werden, dass ein versionierter Typ keine Referenzen auf unversionierte Typen halten kann. Andernfalls könnte sich der Zustand eines stabilen Version nachträglich verändern, wenn in der Folge unversionierte Objekte gelöscht werden. Für Referenzen von unversionierten Objekten gibt es aber keine Einschänkungen. Sie können entweder andere unversionierte oder versionierte Objekte enthalten.

Siehe hierzu auch Datenversionierung.