Beim Attributzugriff muss berechnet werden, welche konkrete Attribut-Überschreibung statsächlich den Zugriff durchführen soll. Da das Attribut in einer Unterklasse mit einer Berechnungsvorschrift überschrieben sein könnte. Hierfür muss die Beziehung der Klasse, die das Attribut definiert mit dem zugegriffen wird und der konkreten Klasse des Objektes auf das zugegriffen wird, bestimmt werden.

Für diese Berechnung ist der Cache TLModelCache verantwortlich/relevant. Dieser ist aber nur für aktuelle Versionen aktiv, da es von historischen Ständen eine fast unbegrenzte Anzahl geben kann und die Cache-Entries nicht abgeräumt werden.

Aufrufpfad beim Attributzugriff:

Verbesserung

Versionierung von Modell und Daten unabhängig voneinander.

Die "Produktionsversion" (die den Zugriff auf die Attribute steuert) des Modells ist immer die aktuelle Version des Modells. Diese ist unabhängig von der Version des Objekts, auf das zugegriffen wird. Dadurch ist es nicht erforderlich, alte Versionen des Modells abzurufen, um auf historische/stabile Versionen der Daten zuzugreifen.

Die Annahme hinter dieser Optimierung ist, dass sich das Modell im Produktionsmodus einer Anwendung nicht ändert. Nur während der Entwicklung kann das Modell geändert werden, und die Änderung spiegelt sich sofort in den Daten wider. Wenn nur konservative Änderungen vorgenommen werden, ist das aktuelle (aktualisierte) Modell auch für den Zugriff auf historische Werte geeignet. Werden während der Entwicklung nicht-konservative Änderungen vorgenommen, kann der Zugriff auf historische Daten fehlschlagen. In fast allen Anwendungen wird jedoch eine Datenmigration durchgeführt, wenn eine neue Softwareversion ausgeliefert wird, die eine nicht konservative Modelländerung enthält. Andernfalls würden historische Ansichten der Daten anders aussehen bzw. sich anders verhalten als aktuelle Daten. Dies ist zwar theoretisch möglich, erschwert aber die Wartung der Anwendung ungemein.

Bei der Datenmigration, die nach einer nicht konservativen Modelländerung erforderlich ist, werden in der Regel alle historischen Versionen des Modells auf die neue aktuelle Version des Modells aktualisiert und alle historischen Daten so aktualisiert, dass sie mit der aktuellen Version des Modells kompatibel sind. Bei dieser Änderung ist der erste Teil der Migration nicht mehr erforderlich, da ohnehin nur die aktuelle Version des Modells verwendet wird. Historische Versionen des Modells dienen nur noch zu Dokumentationszwecken.

Die Änderung erfolgt durch die Verwendung eines speziellen Speichers für die Referenz TLObject#tType, der die Daten an ihr Modell bindet. Während der Verweis ein normaler "aktueller" Verweis ist, der zwei versionierte Objekte desselben historischen Kontexts verbindet, ruft der Speicher immer die aktuelle Version des referenzierten Modellelements ab, wenn ein Wert abgerufen wird. Dadurch bleibt die versionierte Verknüpfung zwischen Daten und Modell in der DB erhalten, aber es wird nur die aktuelle Version des Modells für Operationen mit den Daten verwendet.

Test

Kein zusätzlicher Test.