Der Rückzieher, den die Datenbank nicht vorsah

Jana führt in unserer Bücher-App ein Lesetagebuch. Sie trägt abends ein, auf welcher Seite sie steht, und wenn die Seitenzahl die Gesamtseiten erreicht, schaltet das Buch von selbst auf „Gelesen”. Das funktioniert seit einer Woche.

Nicht funktioniert hat der Fall, dass jemand sich vertippt.

Was passiert, wenn man zurückrudert

Angenommen, der Eintrag war falsch: Seite 412 statt 312, das Buch springt auf „Gelesen”, obwohl noch hundert Seiten fehlen. Man korrigiert das, setzt den Status zurück auf „Lese ich”, liest zu Ende und trägt den richtigen Schlusseintrag ein.

Beim zweiten „Gelesen” an diesem Tag kam ein Datenbankfehler.

Der Grund steckt im Schema, und zwar von Anfang an. Jeder Statuswechsel schreibt ein Ereignis in ein Logbuch, aus dem später die Statistik entsteht: Welche Bücher wurden in welchem Monat fertig, wie viele Seiten waren das, welche Bewertung. Damit diese Statistik nicht lügt, gibt es eine Regel: ein Ereignis pro Buch, Status und Tag. Ohne sie würde ein Buch, das man dreimal hin und her schaltet, als drei gelesene Bücher im Monatsbalken auftauchen.

Die Regel ist richtig. Der Code hat nur nie damit gerechnet, dass sie zuschlägt.

Eine Funktion, die nichts tun durfte

Der ursprüngliche Code sah harmlos aus. Eine Hilfsfunktion baute ein Ereignis-Objekt, gab es zurück, und die aufrufende Stelle hängte es an die Sitzung an:

def log_status(book, user, status, at):
    book.status = status
    return ReadingLog(book_id=book.id, status=status, at=at, ...)

# an zwei Stellen:
db.add(log_status(book, user, "Gelesen", day))

Das ist eine saubere Trennung: Die Funktion kennt die Datenbank nicht, sie baut nur ein Objekt. Nur lässt sich daraus kein „schreib das, oder aktualisiere den vorhandenen Eintrag” machen. Dafür muss jemand die bestehende Zeile kennen, und das kann nur die Datenbank selbst.

Postgres kann das in einem Schritt: einfügen, und falls die Regel verletzt wird, stattdessen die vorhandene Zeile aktualisieren. Dafür musste die Hilfsfunktion aber selbst schreiben dürfen — sie bekommt jetzt die Sitzung übergeben und gibt nichts mehr zurück:

async def log_status(db, book, user, status, at):
    book.status = status
    stmt = pg_insert(ReadingLog).values(..., pages=book.pages, rating=book.rating)
    await db.execute(stmt.on_conflict_do_update(
        constraint="uq_readinglog",
        set_={"pages": stmt.excluded.pages, "rating": stmt.excluded.rating},
    ))

Aktualisiert werden Seitenzahl und Bewertung. Das ist Absicht: Wenn beim ersten Versuch noch keine Seitenzahl eingetragen war und beim zweiten schon, soll die Statistik den besseren Wert bekommen. Der Zeitpunkt bleibt, wie er ist — es war ja derselbe Tag.

Dieselbe Behandlung bekam die zweite Stelle, an der Status gesetzt wird: das manuelle Umschalten in der Buchansicht. Dort stand vorher sogar noch eine eigene Kopie derselben Zeile, inklusive der Sonderlocke, dass „Gelesen” das Lesedatum als Ereignistag nimmt statt heute. Zwei Kopien derselben Logik an zwei Stellen, eine davon mit Upsert und eine ohne — das wäre genau die Sorte Reparatur, die in sechs Wochen den nächsten Fehlerbericht erzeugt.

Was ich daraus mitnehme

Der interessante Teil ist nicht die Postgres-Syntax, sondern die Annahme darunter.

Die Regel „ein Ereignis pro Buch, Status und Tag” beschreibt, wie die Welt aussehen soll. Der Code daneben behandelte sie als Beschreibung dessen, was ohnehin passiert — als könne es gar nicht vorkommen, dass jemand denselben Übergang zweimal auslöst. Solche Regeln sind aber keine Vorhersage. Sie sind ein Versprechen, das irgendwer einlösen muss, und wenn es der Code nicht tut, tut es die Datenbank. Mit einer Fehlermeldung.

Hübsch ist, dass der Fehler erst auffiel, als die App gut genug wurde, um Korrekturen zu erlauben. Solange man nur vorwärts eintragen konnte, gab es nichts zu wiederholen. Das Lesetagebuch und der Seiten-Eintrag sind beide erst eine Woche alt — der Bug ist sozusagen ein Nebenprodukt davon, dass die App inzwischen benutzt wird, statt nur angeschaut zu werden.

Fünfzehn Zeilen hat die Reparatur gekostet. Das Nachdenken darüber, warum eine Regel aus dem ersten Schema erst jetzt zubeißt, deutlich länger.