Aufbewahrung¶

viur-revision bringt einen PeriodicTask (cleanup_revisions) mit, der einmal täglich läuft und die Revisionshistorie pro Ursprungs-Entität ausdünnt. Ohne ihn würden die Revisionstabellen unbegrenzt wachsen.

Bucket-Politik¶

Alter der Revision	Aufbewahrung
< 24 Stunden	alle behalten
1 Tag – 7 Tage	neueste pro Stunden-Slot
7 Tage – 30 Tage	neueste pro Tages-Slot
> 30 Tage	neueste pro Wochen-Slot

Innerhalb jedes Buckets gewinnt die Revision mit dem jüngsten revision_date; der Rest wird gelöscht. Der Task verarbeitet einen Ursprung nach dem anderen, damit der Speicherbedarf vorhersehbar bleibt.

Warum diese Buckets?¶

Die meisten „Was hat sich wann geändert?"-Fragen betreffen die jüngere Vergangenheit. Näher an der Gegenwart willst du feine Auflösung (der Auto-Save-Schwall von heute früh), weiter zurück genügt ein repräsentativer Schnappschuss.

Brauchst du für ein bestimmtes Modul eine andere Taktung, überschreibe cleanup_revisions und nutze die Helfer weiter:

class Example(RevisionModule, List):

    @PeriodicTask(datetime.timedelta(hours=6))
    def cleanup_revisions(self):
        # eigene Taktung — auf Standard-Ausdünnung zurückgreifen
        return self._run_cleanup_revisions()

Manueller Auslöser¶

Der tägliche Task lässt sich bei Bedarf über cleanup_revisions_now aus dem Browser oder per curl anstoßen:

curl https://app.example/example/cleanup_revisions_now

Der Endpunkt liefert eine Diagnose-Payload zurück, die jede verarbeitete Revision auflistet, in welchen Bucket sie fiel und ob sie behalten oder gelöscht wurde — nützlich beim Debuggen der Politik.

Sonderfälle¶

Revisionen ohne revision_date (z. B. anderswo importierte Daten) werden immer behalten.
Revisionen, deren Datumsarithmetik fehlschlägt (z. B. naive und zeitzonenbehaftete Datetimes vermischt) werden behalten, und der Fehler wird in der Diagnose-Ausgabe vermerkt.
Ursprünge mit nur einer Revision werden nie angetastet.