Versioning: planung der nächsten implementationsphasen
Phase 6
Issue: #360 (closed)
API Erweiterungen
- Entity XML
head="true/false"
-
<Entity>@HEAD
zusätzlich zu<ENTITY>@<VERSION>
zur Bezeichnung der aktuellsten Version. - Entity XML enthät Predecessor/Successor Version. e.g.
<Record id="2345"> <Version id="1234ABCD" date="2020-04-02T12:20:23"> <Predecessor id="2345BCDE" date="2020-04-02T08:23:23"/> <Successor id="3457CDEF" date="2020-05-02T20:15:00"/> </Version> </Record>
Tests in pyinttest verlangen ein Enhancement in pylib:
Entity.version = Version(id="123ABC", date="2020-04-02T12:20:23", predecessors=<list of Version>, successors=<list of Version>)
Phase 7
Issue: caosdb-mysqlbackend#63 (closed)
Backend Refactoring für spätere Phasen (Query, Delete/Forget)
- Backend: Refactoring:
archive_*_data
Tables in Partitions der normalen*_data
Tables umwandeln.- Query: Als rückwärtskompatible Implementation vorerst nur die HEAD partition auswerten.
Phase 8
Issue: #359 (closed)
Reference Values referenzieren immer bestimmte Versionen einer Entity (e.g. 1234@123ABC
) oder die jeweils aktuellste Version (e.g. 1234@HEAD
). Wenn nicht anders angegeben, ist HEAD
immer der Default. Dies könnte in Zukunft für bestimmte Kontexte anders definiert werden, z.B. durch bestimmte Parents.
- Backend
reference_data
: Einfügen einer Column_iversion INT UNSIGNED DEFAULT NULL, FOREIGN KEY (value, _iversion) REFERENCES entity_version (entity_id, _iversion)
. Diese istNULL
, wenn derHEAD
der Entity gemeint ist, und zeigt ansonsten auf die interne Versionsnummer. - Backend: Hash- und Versionberechnung aus dem Backend entfernen und im Server ansiedeln, für HASH NULL zulassen.
- Server:
ReferenceValue
Klasse anpassen. - Backend:
insertEntityProperty
parsen der String-Representation1234@123ABC
. - Backend:
registerSubdomain
dummy version in entity_versioning eintragen. - Backend:
retrieveEntityProperty
, zusammensetzen der String-Representation. - Python: keine Änderungen.
Phase 8.5
Issue #361 (closed)
- Strategie überdenken für das nachträgliche An-/Ausschalten des Features bei nicht-leerer Datenbank.
Phase 9
Issue: caosdb-webui#372 (closed)
Webinterface anpassen
- Versionsnummer und -Datum anzeigen
- edit_mode muss immer auf
HEAD
arbeiten. edit button sollte bei nicht-HEAD ausgeblendet werden (mit hinweis) - Nicht-Head entities als solche kennzeichnen und link zum HEAD anzeigen.
- Link auf direkte Vorgängerversionen.
Phase 10
Issue: #271
Delete
(umkehrbar) und Forget
(unumkehrbar)
- Delete verschiebt komplett Entities in spezielle Datenbankbereiche (Tables/Partitionen).
- Forget löscht alle Properties und Parents, name, description etc. unwiderruflich und lässt im Fall der Fälle eine Entity ohne irgendwelche Eigenschaften oder Versionsgeschichte zurück (quasi eine ID ohne Entity).
Diese Implementationsphase ist nicht ganz unwichtig, weil ansonsten das Versioning in Verbindung mit den geltenden Foreign-Key Constraints im Backend dazu führen, dass das Löschen von Entities, die einmal in irgendeiner Version einer Entity referenziert wurden de-facto nicht möglich ist.
Phase 11
Issue: #270
Query, e.g. FIND ENTITY WITH <version filter>
and version filters
VERSION (OLDER THAN|YOUNGER THAN) 2 days
VERSION OLDER THAN "2345@123ABC"
VERSION FROM 2020-02
ANY VERSION
- ...
- Permissions
- Transaction Filter (
... WHICH HAS BEEN INSERTED BY user1 IN 2020-03
)
Maybe even a FIND DELETED ENTITY WITH ...
Phase N+1
Issue: https://gitlab.indiscale.com/caosdb/internal/all/-/issues/1475
Schöne neue Features
- Nachträgliches Anonymisieren von Versionen mit persönlichen Daten.
- Version im Request wird bei Update/Delete überprüft - so kann man sicher sein, nichts zu löschen/überschreiben, was man nicht möchte.
- Parents und AbstractProperties führen die Version mit, sodass ggf. alte Entities auch bei einem (geringfügigen) Update in der alten Form bleiben können.
- Versionen einfügen ohne HEAD update -> Für das Einfügen von Änderungsvorschlägen (Geomar), für Crawler updates, die erst verifiziert/authorisiert werden müssen (AWI, BMPG). Für spannendere Edit-Wars (IndiScale).