Worum es geht
Ein Datei-Modell hat zwei Teile: den Datensatz in der Datenbank und den Inhalt im Dateispeicher. Ist das Modell auditiert, bleibt jeder alte Inhalt als Version liegen, und jede Revision des Datensatzes merkt sich in fileVersion, welcher Inhalt zu ihr gehört. Siehe Dateiversionen.
Ein Rollback setzt beide Teile gemeinsam zurück: den Datensatz auf den Stand der Revision und den Inhalt auf die Version, die in dieser Revision steht.
Vorher und nachher im Speicher
Ein Vertrag wurde dreimal hochgeladen. Jetzt wird er auf die Revision der ersten Fassung zurückgesetzt:
Vorher – der Datensatz trägt fileVersion 1790000300000:
| Datei im Speicher | Inhalt |
|---|---|
<fileId> | „Fassung drei“ (aktuell) |
<fileId>.1790000200000 | „Fassung zwei“ |
<fileId>.1790000100000 | „Fassung eins“ |
Nachher – POST /fileasset/f1…/rollback/17, der Datensatz trägt fileVersion 1790000100000:
| Datei im Speicher | Inhalt |
|---|---|
<fileId> | „Fassung eins“ (aktuell, eine Kopie) |
<fileId>.1790000300000 | „Fassung drei“ (neu als Version gesichert) |
<fileId>.1790000200000 | „Fassung zwei“ |
<fileId>.1790000100000 | „Fassung eins“ (bleibt als Version liegen) |
Der aktuelle Inhalt bekommt die Kennung der Version, von der er eine Kopie ist. Datensatz und Inhalt passen also wieder zusammen: fileVersion 1790000100000 heißt „Fassung eins“.
Der Ablauf
-
1Client→CDMS
POST /fileasset/f1…/rollback/17mitresponse -
2CDMSprüft Sichtbarkeit und Rollback-Rolle wie bei jedem Rollback
-
3CDMSmerkt sich die
fileVersion, die der Datensatz jetzt trägt: 1790000300000Das ist die Kennung des Inhalts, der gerade im Speicher liegt. -
4CDMS→Datenbanksetzt den Datensatz auf Revision 17 zurück. Er trägt jetzt
fileVersion 1790000100000. -
5CDMS→DateispeicherGibt es die Version 1790000100000?Nein → 500
file-version-not-found, die Änderung in der Datenbank wird verworfen. -
6CDMS→Dateispeicherkopiert
<fileId>.1790000100000in eine Zwischendatei neben<fileId>Kopieren, nicht verschieben: Die Version bleibt liegen und kann später wieder zurückgeholt werden. Aktuell ist weiterhin „Fassung drei“. -
7CDMSsetzt
fileSizeundmimeTypenach dem zurückgeholten Inhalt -
8CDMS→DatenbankAfter-Hooks, flush, zurücklesen, CommitScheitert hier etwas, wird die Zwischendatei verworfen. Datensatz und Inhalt bleiben auf „Fassung drei“.
-
9CDMS→Dateispeicherbenennt den aktuellen Inhalt in
<fileId>.1790000300000um und die Zwischendatei in<fileId>So bleibt „Fassung drei“ erhalten, und „Fassung eins“ ist in einem Schritt aktuell.Ergebnis:GET /fileasset/f1…/fileliefert „Fassung eins“. Die Historie hat eine neueMOD-Revision.
Warum der aktuelle Inhalt vorher gesichert wird
Ohne diesen Schritt würde der Rollback den aktuellen Inhalt überschreiben. „Fassung drei“ wäre dann weg, obwohl die Historie noch eine Revision mit fileVersion 1790000300000 enthält. Ein Rollback auf diese Revision fände keinen Inhalt mehr.
So aber gilt dieselbe Regel wie für den Datensatz: Die Geschichte wird nicht umgeschrieben. Jede Revision findet ihren Inhalt, auch die Revision direkt vor dem Rollback.
Die Ausprägungen
Wann: Die Zielrevision nennt eine andere Version als der aktuelle Stand.
Der aktuelle Inhalt wird zur Version, die Zielversion wird an den aktuellen Platz kopiert.
Ergebnis: Download liefert den alten Inhalt.
Wann: Nach dem Rollback auf 17 wird auf die Revision davor zurückgesetzt.
Der aktuelle Inhalt ist eine Kopie von Version 1790000100000, die es schon gibt. CDMS legt sie deshalb nicht doppelt ab, sondern entfernt nur die Kopie. Dann kopiert es Version 1790000300000 zurück.
Ergebnis: „Fassung drei“ ist wieder aktuell, im Speicher liegt keine Datei doppelt.
Wann: Nach dem Rollback wird ein neuer Inhalt hochgeladen.
Auch hier ist der aktuelle Inhalt nur eine Kopie einer vorhandenen Version. Er wird entfernt statt ein zweites Mal gesichert, und der neue Inhalt nimmt seinen Platz ein.
Wann: Die Zielrevision stammt aus der Zeit, bevor der Datensatz eine fileVersion hatte.
Der Datensatz wird zurückgesetzt, der Inhalt bleibt, wie er ist. CDMS kann keinem Inhalt sicher sagen, dass er zu dieser Revision gehört, und rät nicht.
Wann: Seit der Zielrevision wurde nur der Datensatz geändert, etwa umbenannt, aber kein neuer Inhalt hochgeladen.
Die Zielrevision nennt dieselbe fileVersion wie der aktuelle Stand. Der Inhalt ist also schon der richtige. CDMS setzt nur den Datensatz zurück und lässt den Inhalt, wie er ist.
Ergebnis: Der alte Name und die übrigen Felder sind zurück, der Download liefert denselben Inhalt wie vorher.
Name, Größe und Typ
| Feld | Nach dem Rollback |
|---|---|
name | der Name aus der Zielrevision, wie jedes einfache Feld |
fileVersion | die Kennung der zurückgeholten Version |
fileSize | neu gemessen am zurückgeholten Inhalt |
mimeType | neu bestimmt aus der Endung des Namens, wie beim Hochladen |
fileId | bleibt, sie bestimmt den Ort im Speicher |
Fallen
Wie es weitergeht
- Wie Versionen entstehen: Dateiversionen
- Wo die Dateien liegen: Ablage und Mandantentrennung im Speicher
- Rollback allgemein: Auf einen alten Stand zurücksetzen