Dateiversionen

Bei auditierten Datei-Modellen bleibt jeder alte Stand erhalten. Wie die Versionen abgelegt werden, wie Revision und Inhalt zusammenhängen und wann einfach überschrieben wird.

Ausprägungen

auditiert → Versionennicht auditiert → überschriebenRevision und Version gehören zusammenZugriff nur über RollbackAuditing nachträglich einschaltenkein automatisches Aufräumen

Worum es geht

Lädst du für ein Datei-Modell einen neuen Inhalt hoch, ersetzt er den alten. Ob der alte dabei verloren geht, entscheidet ein einziger Schalter: ob das Modell auditiert ist. Siehe Was auditiert wird.

Wie Versionen abgelegt werden

Drei Uploads auf denselben Datensatz eines auditierten Modells:

Datei im Speicher	Inhalt	Rolle
`<fileId>`	„Fassung drei“	aktueller Inhalt, immer unter dem Namen ohne Zusatz
`<fileId>.1790000200000`	„Fassung zwei“	Version
`<fileId>.1790000100000`	„Fassung eins“	Version

Vor jedem Upload benennt CDMS den bisherigen aktuellen Inhalt um und hängt dabei eine Versionskennung an. Dann legt es den neuen Inhalt unter dem Namen ohne Zusatz ab. Die Kennung ist eine Zahl, größer heißt neuer. Sie steht als fileVersion im Datensatz.

Revision und Version gehören zusammen

fileVersion ist ein normales Feld des Datensatzes. Die Historie hält es deshalb in jeder Revision fest. So weiß jede Revision, welcher Inhalt damals aktuell war:

flowchart LR
    R1["Revision 17 · ADD<br/>fileVersion 1790000100000"] --> V1["Fassung eins"]
    R2["Revision 42 · MOD<br/>fileVersion 1790000200000"] --> V2["Fassung zwei"]
    R3["Revision 57 · MOD<br/>fileVersion 1790000300000"] --> V3["Fassung drei (aktuell)"]

An eine alte Version kommen

Einen eigenen Endpunkt zum Herunterladen einer alten Version gibt es nicht. Der Weg führt über die Historie und einen Rollback:

1

Client→CDMS
POST /fileasset/f1…/history mit ["name", "fileSize", "fileVersion"]

Die Revisionen zeigen, wann welcher Inhalt hochgeladen wurde und von wem.
2

Client→CDMS
POST /fileasset/f1…/rollback/42
3

CDMS→File storage
hebt den aktuellen Inhalt als neue Version auf und kopiert Version 1790000200000 an den aktuellen Platz
4

CDMS→Database
setzt den Datensatz auf Revision 42 zurück; das ist selbst eine neue Revision

Ergebnis: GET /fileasset/f1…/file liefert jetzt „Fassung zwei“. „Fassung drei“ ist als Version erhalten, der Rollback lässt sich also wieder zurücknehmen.

Details unter Rollback bei Dateien.

Auditiert oder nicht

Neuer Upload auf einen bestehenden Datensatz

Auditiert

alter Inhalt wird zur Version
Historie und Rollback-Endpunkte gibt es
jede Revision kennt ihren Inhalt
Speicherbedarf wächst mit jedem Upload

Nicht auditiert

alter Inhalt wird überschrieben
keine Historie, kein Rollback
Wiederherstellen nur aus einer Sicherung der Infrastruktur
Speicherbedarf bleibt bei einer Datei je Datensatz

Besondere Fälle

Versionen über die Zeit

Auditing nachträglich einschaltenAuditing ausschaltenDatensatz löschen

Wann: Ein bestehendes Datei-Modell wird im Hub auf auditiert gestellt und neu generiert.

Es braucht keine Migration. Bestehende Dateien haben einfach noch keine Versionen. Die erste entsteht beim nächsten Upload.

Wann: Das Modell wird auf nicht auditiert gestellt.

Neue Uploads überschreiben ab dann. Schon vorhandene Versionen bleiben im Speicher, bis der Datensatz gelöscht wird.

Wann: DELETE auf das Datei-Modell, direkt oder per Kaskade

Der aktuelle Inhalt und alle Versionen werden entfernt.

Ergebnis: Siehe Datei-Modelle löschen.

Fallen

Wie es weitergeht

Wie ein Upload ersetzt: Ersetzen und Umbenennen
Zurück auf einen alten Stand: Rollback bei Dateien
Wo die Dateien liegen: Ablage und Mandantentrennung im Speicher