Was eine Löschung wirklich anfasst
Einen Zähler zu löschen leert hier 33 Tabellen. Gestern leerte es 25.
Die acht, die es übersah, waren allesamt am Tag davor entstanden, zwischen 11:10 vormittags und 15:10 nachmittags.
Wie die Löschung arbeitet
Ein Besitzer kann seinen Zähler löschen. Es braucht ein POST, das Besitzer-Token und die Zählernummer von Hand abgetippt, denn es gibt kein Zurück. Nichts wird beiseitegelegt: eine Schattenkopie wäre das Gegenteil dessen, worum gebeten wurde, und die Export-Verweise stehen über dem Knopf für alle, die eine wollen.
Dann wird eine Liste von Tabellen in einer einzigen Transaktion geleert, die Haupttabelle zuletzt, und ein Grabstein geht ins Archiv, damit die Nummer nie an jemand anderen gehen kann. Scheitert ein Teil, rollt das Ganze zurück. Nichts gelöscht ist besser als halb gelöscht.
Über dieser Liste steht in der Datei:
„Jede Tabelle, die etwas über diesen Zähler weiß. Als Liste und nicht verstreut im Code: was hier fehlt, bleibt sonst als verwaiste Zeile zurück, und niemand merkt es."
Sie hat ihren eigenen Fall einen Tag im Voraus beschrieben
Gestern kamen sechs neue Tabellen für eine neue Funktion dazu — Verweildauer, Scrolltiefe, Ausstiegsseiten — und zwei weitere. Zwischen 11:10 und 15:10.
Die Löschliste wurde am selben Tag angefasst, um eine andere neue Tabelle einzutragen. Die acht kamen danach, und die Liste bewegte sich nicht mehr. Seit gestern Nachmittag ließ eine Löschung also 4.840 Zeilen Verhaltensdaten zurück, verteilt auf acht Tabellen, gehörend zu Menschen, die um Vergessenwerden gebeten hatten.
Das ist keine Geschichte über Nachlässigkeit. Jemand hat die Liste geschrieben, genau verstanden, warum sie eine Liste ist, aufgeschrieben, was passiert, wenn sie hinterherhinkt — und sie an ebendiesem Tag für eine Tabelle nachgezogen. Und sie hinkte trotzdem hinterher, weil zwei Dinge dadurch im Gleichschritt zu halten, dass man daran denkt, etwas ist, das Menschen zuverlässig tun, bis zu dem Nachmittag, an dem sie es nicht tun.
Die Behebung, und die andere Behebung
Die acht Namen stehen jetzt in der Liste. Sie wurden an ihren alphabetischen Platz gesetzt statt angehängt, denn eine sortierte Liste macht eine Lücke sichtbar und eine angehängte nicht.
Das ist die kleine Behebung. Die, auf die es ankommt, ist ein Skript, das die Datenbank fragt, welche Tabellen eine Zählernummer tragen, die Liste aus der Quelldatei liest statt sie zu wiederholen, und beides vergleicht. Wer eine Tabelle anlegt, lässt es einmal laufen. Es kann nicht auf die Art vergessen werden, auf die eine Liste vergessen wird, weil es nichts speichert — es leitet die Antwort jedes Mal aus dem Schema ab.
Beim ersten Lauf fand es noch etwas: 25 Zeilen in acht weiteren Tabellen, deren Zählernummer weder in der laufenden Tabelle noch im Archiv steht. Keine gelöschten Zähler — die hinterlassen einen Grabstein. Nummern, die zu gar nichts gehören, die meisten davon offensichtliche Testnummern aus der Zeit vor der Archivprüfung. Sie wurden in eine Datei außerhalb des Web-Verzeichnisses geschrieben und dann entfernt.
Worauf das hinausläuft
Jede Liste, die mit etwas anderem im Gleichschritt gehalten werden muss, wird irgendwann aus dem Gleichschritt fallen, und die Lücke wird unsichtbar sein, denn eine Liste, der ein Eintrag fehlt, sieht genauso aus wie eine vollständige.
Die Abwehr ist nicht Disziplin. Sie besteht darin, die eine Seite aus der anderen abzuleiten und zu prüfen, dass beide übereinstimmen — und diese Prüfung in dem Augenblick laufen zu lassen, in dem jemand die Sache anlegt, nicht in dem, in dem jemand sich wundert.
Der Kommentar über der Liste hatte in allem recht bis auf ein Wort. Er sagte, niemand merkt es. Jemand hat es gemerkt, einen Tag später, weil er mit einem Skript nachgesehen hat statt mit seinem Gedächtnis.