Analyse typischer Fehler bei der Entwicklung von Triggern

Also, liebe Studis, ihr habt jetzt schon einiges über Trigger gelernt, kennt die Typen, wie sie funktionieren und habt sogar schon eigene Trigger gebaut, um verschiedene Aufgaben zu lösen. Aber wie so oft beim Programmieren: Es ist wichtig zu wissen, was man machen kann – aber mindestens genauso wichtig ist es zu wissen, was man lieber lassen sollte. Heute schauen wir uns typische Fehler an, die Entwickler:innen beim Arbeiten mit Triggern machen, damit ihr sie vermeiden könnt und euch ein paar Stunden (oder sogar Tage) Debugging spart.

Trigger-Rekursion: Trigger ruft sich selbst auf

Das ist wahrscheinlich der Klassiker unter den Anfängerfehlern. Stell dir vor, du hast einen Trigger gebaut, der einen Wert in einer Spalte aktualisiert, zum Beispiel last_modified. Sobald diese Änderung passiert, löst das Update aber wieder den Trigger aus. Das ist ein Endlos-Loop und am Ende crasht dein Server mit einem Stack Overflow.

Beispiel:

CREATE OR REPLACE FUNCTION update_last_modified()
RETURNS TRIGGER AS $$
BEGIN
    -- Aktualisiere das Feld last_modified
    UPDATE my_table
    SET last_modified = NOW()
    WHERE id = NEW.id;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER after_update
AFTER UPDATE ON my_table
FOR EACH ROW
EXECUTE FUNCTION update_last_modified();

Was läuft hier schief? Das UPDATE in der Funktion löst genau den Trigger aus, der es aufgerufen hat. Voilà, Endlosschleife.

Wie vermeiden:

Benutze die Variable OLD und vergleiche die Werte, bevor du etwas änderst:

CREATE OR REPLACE FUNCTION update_last_modified_safe()
RETURNS TRIGGER AS $$
BEGIN
    -- Prüfe, ob sich der Wert geändert hat
    IF NEW.last_modified IS DISTINCT FROM OLD.last_modified THEN
        NEW.last_modified = NOW();
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Stell sicher, dass du keine unnötigen Operationen im Trigger ausführst.

Falsche Verwendung von OLD und NEW

Diese Variablen sind echt deine Freunde beim Arbeiten mit Triggern, aber in unerfahrenen Händen können sie für ordentlich Kopfzerbrechen sorgen. OLD enthält die Daten vor der Änderung, NEW die Daten, die nach der Änderung gespeichert werden.

Ein häufiger Fehler ist, dass man sie falsch interpretiert oder versucht, sie dort zu benutzen, wo sie gar nicht verfügbar sind. Zum Beispiel: Bei einem BEFORE INSERT-Trigger gibt es kein OLD – die Zeile wird ja gerade erst erstellt.

Fehlerbeispiel:

-- Das führt zu einem Fehler, weil OLD beim Insert nicht existiert
CREATE OR REPLACE FUNCTION log_inserts()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO audit_log (old_data, new_data)
    VALUES (OLD.my_column, NEW.my_column);
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Wie vermeiden:

Überlege dir genau, wann du OLD und NEW verwendest:

• OLD gibt's bei UPDATE und DELETE-Operationen.
• NEW gibt's bei INSERT und UPDATE-Operationen.

Mehrere Trigger auf eine Operation

In PostgreSQL kannst du mehrere Trigger für dieselbe Operation und Tabelle anlegen. Klingt erstmal praktisch, aber in Wirklichkeit kann das schnell chaotisch werden, wenn die Trigger sich gegenseitig in die Quere kommen oder dieselben Daten ändern.

Beispiel:

-- Trigger 1
CREATE OR REPLACE FUNCTION trigger_one()
RETURNS TRIGGER AS $$
BEGIN
    -- Logik von Trigger 1
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Trigger 2
CREATE OR REPLACE FUNCTION trigger_two()
RETURNS TRIGGER AS $$
BEGIN
    -- Logik von Trigger 2
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Zwei Trigger anlegen
CREATE TRIGGER trigger_one AFTER INSERT ON my_table EXECUTE FUNCTION trigger_one();
CREATE TRIGGER trigger_two AFTER INSERT ON my_table EXECUTE FUNCTION trigger_two();

Beide Trigger feuern beim Einfügen einer Zeile in my_table. Wenn die Logik nicht sauber abgestimmt ist, kann das zu unvorhersehbaren Ergebnissen führen.

Wie vermeiden:

• Plane die Trigger-Architektur im Voraus.
• Wenn Trigger dieselbe Logik betreffen, pack sie lieber in einen einzigen Trigger.

Performance-Probleme

Trigger sorgen für zusätzliche Berechnungen bei jeder Operation, an die sie gekoppelt sind. Wenn du Trigger auf Tabellen mit vielen Operationen oder Datensätzen verwendest, kann das die Performance ordentlich runterziehen.

Fehlerbeispiel:

CREATE OR REPLACE FUNCTION heavy_trigger_function()
RETURNS TRIGGER AS $$
BEGIN
    -- Schwere Operation, die bei jedem Update ausgeführt wird
    PERFORM some_heavy_query();
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER performance_killer AFTER UPDATE ON huge_table EXECUTE FUNCTION heavy_trigger_function();

Wie vermeiden:

• Halte die Logik im Trigger so minimal wie möglich. Wenn du eine schwere Operation brauchst, überleg, ob du sie nicht lieber als Background-Job laufen lässt.
• Nutze Bedingungen für die Trigger-Ausführung, zum Beispiel mit WHEN:

CREATE TRIGGER optimized_trigger
AFTER UPDATE ON my_table
WHEN (OLD.column_name IS DISTINCT FROM NEW.column_name)
EXECUTE FUNCTION light_function();

Trigger und Transaktionen

Trigger laufen immer im Rahmen der Transaktion, die dein Query gestartet hat. Wenn im Trigger ein Fehler passiert, wird die ganze Transaktion zurückgerollt. Das kann in manchen Fällen praktisch sein, aber auch zu unerwarteten Problemen führen, wenn das Error-Handling nicht durchdacht ist.

Fehlerbeispiel:

CREATE OR REPLACE FUNCTION error_prone_trigger()
RETURNS TRIGGER AS $$
BEGIN
    -- Fehler wird erzeugt
    RAISE EXCEPTION 'Etwas ist schiefgelaufen!';
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Wenn dieser Trigger feuert, wird die Transaktion deines Haupt-Queries zurückgerollt.

Wie vermeiden:

Bau Error-Handling in deine Trigger ein, um die Auswirkungen auf die Haupt-Transaktion zu minimieren:

CREATE OR REPLACE FUNCTION safe_trigger()
RETURNS TRIGGER AS $$
BEGIN
    BEGIN
        -- Code, der einen Fehler werfen könnte
        INSERT INTO another_table VALUES (NEW.data);
    EXCEPTION
        WHEN OTHERS THEN
            RAISE NOTICE 'Ein Fehler ist aufgetreten, aber wir haben ihn abgefangen.';
    END;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Praktische Tipps

1. Halte Trigger so einfach wie möglich. Wenn du das Gefühl hast, dass ein Trigger zu groß oder zu kompliziert wird, solltest du ihn lieber aufteilen oder die Logik nochmal überdenken.

2. Teste Trigger immer erst mit kleinen Datenmengen. Bevor du einen Trigger auf eine wichtige Tabelle loslässt, probier ihn erstmal in einer Testumgebung aus.

3. Dokumentiere deine Trigger. In ein paar Monaten weißt du (oder deine Kolleg:innen) vielleicht nicht mehr, warum ein bestimmter Trigger überhaupt existiert. Gute Doku erspart dir Kopfschmerzen.

4. Vermeide Trigger für Dinge, die du auch auf Applikationsebene lösen kannst. Trigger sind super für Automatisierung, die sofort passieren muss, aber für komplexe Business-Logik können sie später Probleme machen.

5. Behalte die Performance im Auge. Überwache regelmäßig, wie sich Trigger auf die Performance deiner Datenbank auswirken – besonders, wenn deine Daten oder die Last wachsen.

Mit diesen Tipps und dem Wissen aus dieser Vorlesung bist du jetzt bereit, nicht nur Trigger zu bauen, sondern solche, die richtig, effizient und ohne böse Überraschungen funktionieren.