Aus historischen Gründen verwenden wir sowohl Enver als auch einen benutzerdefinierten Prüfmechanismus. Einige Tabellen werden von Envers geprüft, aber eine Tabelle und die meisten abhängigen Tabellen werden manuell geprüft.So migrieren Sie bereits vorhandene benutzerdefinierte Protokolltabellen nach envers
Unsere benutzerdefinierte Lösung erstellt eine Kopie des Objektdiagramms, fügt einen Zeitstempel hinzu und speichert die * Verlaufsobjekte in den entsprechenden Tabellen.
Nehmen wir an, wir haben eine Entität A, die auf eine Auflistung von Entitäten B verweist, die auf eine Auflistung von Entitäten C verweist. Wenn wir ein Update oder eine Einfügung von A feststellen, erstellen wir eine Kopie A_History, die auf eine Auflistung von Entitäten B_History verweist, die auf eine Auflistung von Entitäten C_History verweist. Alle Eigenschaften der referenzierten Entitäten werden in das entsprechende * Verlaufsobjekt kopiert und das vollständige Diagramm wird beibehalten. In Wirklichkeit haben wir es mit 12 Tabellen zu tun, die den Objektgraphen darstellen.
Um den alten Code loszuwerden und das Verhalten zu vereinheitlichen, möchten wir alle Auditing auf envers migrieren. Aber natürlich möchten wir die bereits existierende Geschichte bewahren, auch wenn sie nicht von envers erstellt wurde.
Ich habe einige Anleitungen gefunden, um erste Revisionsinformationen zu erstellen, wenn envers in einem bestehenden Projekt eingeführt wird. Aber ich habe keine Hilfe gefunden, um bereits existierende Revisionsinformationen zu migrieren, die nicht von envers verwaltet werden.
Gibt es eine Möglichkeit, die Migration durchzuführen, abgesehen von dem Schreiben roher SQL-Anweisungen?