Der Kalender war das Erste, wofür ich Algebra überhaupt zu bauen begann, und lange hielt ich ihn für den einfachsten Teil des Projekts. Der Schüler wählt einen Termin, gibt seine Daten ein und bekommt eine Bestätigung, und ich sehe die Buchung im Admin-Bereich. Ein paar Wochen um den Jahreswechsel herum war dieser einfache Mechanismus aber mein größtes Problem, denn die Buchungen verschwanden einfach.
Das ist die wichtigste Lehre aus dem ganzen Projekt, deshalb beschreibe ich sie genau, samt der Wege, die sich als Sackgassen erwiesen haben.
Was der Kalender können musste
Von Anfang an wollte ich Einzel- und Gruppenstunden in einem einzigen Kalender haben, und das bedeutete mehr als eine einfache Liste freier Uhrzeiten. Jede Stunde hat ihre eigene Dauer, Gruppen haben eine begrenzte Zahl an Plätzen, und ich muss Termine sperren, Urlaub eintragen und Stunden verschieben können. Dazu kamen ein Kontaktformular, Nachrichten im Admin-Bereich und E-Mails: eine Buchungsbestätigung für den Schüler, eine Benachrichtigung für mich und später eine Erinnerung mit dem Link zur Stunde.
Die E-Mails habe ich anfangs aus einem ganz normalen Gmail-Postfach verschickt, das die Anwendung so benutzte, wie es ein E-Mail-Programm tut. Im kleinen Maßstab hat das gereicht, und im Februar kamen noch Benachrichtigungen aufs Handy und per WhatsApp dazu, damit eine neue Buchung nicht warten muss, bis ich in mein Postfach schaue.
Die Symptome
Im November fingen seltsame Dinge an. Nachdem ich eine neue Version auf den Server gespielt hatte (Informatiker nennen das Deployment), zeigte die Seite manchmal einen Fehler an, weil die Tabelle mit den Buchungen oder den Nachrichten plötzlich aus der Datenbank verschwunden war. Im Admin-Bereich gesetzte Terminsperren gingen verloren, und mit ihnen Buchungen, obwohl niemand sie storniert hatte.
Ich suchte den Fehler dort, wo es logisch schien, nämlich im Code. Ich baute eine Absicherung ein, damit eine fehlende Tabelle nicht die ganze Seite lahmlegt, eine eigene Seite, auf der ich nachsehen konnte, was im Inneren passiert, und das Wiederherstellen fehlender Tabellen bei jedem Start der Anwendung. Ende November ließ ich sie außerdem genau mitschreiben, was beim Speichern der Sperren geschieht, weil ich vermutete, dass das Speichern irgendwo unterwegs schiefgeht. Jede dieser Korrekturen linderte die Symptome, aber keine beseitigte die Ursache.
Die Ursache: eine Festplatte ohne Gedächtnis
Algebra lief im kostenlosen Tarif von Render, der Firma, bei der mein Server stand, und die ganze Datenbank war eine einzige Datei auf derselben Festplatte wie die Anwendung. Was ich damals nicht wusste, lässt sich aus dem Code nicht herauslesen, weil es vom Server abhängt: Jedes Mal, wenn eine neue Version aufgespielt wird, baut Render die Anwendung neu, auf einer leeren Festplatte. Alles, was die Anwendung seit dem letzten Mal bei sich gespeichert hat, ist weg.
Das erklärte alles auf einmal. Ich habe oft neue Versionen aufgespielt, manchmal mehrmals am Tag, und genauso oft fiel die Datenbank auf den Stand zurück, in dem sie zusammen mit dem Code lag. Es verschwanden nicht nur Buchungen, sondern alles, was die Anwendung in Dateien auf dem Server aufbewahrte: Einstellungen, Urlaube und Nachrichten. Der Code tat genau das, was er tun sollte. Er speicherte die Daten nur an einem Ort, der von vornherein nur vorübergehend ist.
Drei Anläufe für die Datenbank
Zuerst habe ich versucht, Ordnung in das zu bringen, was ich hatte, und Nachrichten und Einstellungen aus einzelnen Dateien in die Datenbank verschoben, damit alles an einem Ort liegt. Das Problem blieb, denn dieser eine Ort stand immer noch auf der Festplatte, die alles vergaß.
Im Januar probierte ich eine ungewöhnliche Lösung: Ich zog die Datenbank nach Google Sheets um. Die Anwendung las und schrieb die Daten in einer Tabelle, sie lagen also endlich außerhalb des Servers, und ich konnte sie wie in jeder Tabellenkalkulation ansehen, korrigieren oder exportieren. Das funktionierte, aber langsam, weil jeder Griff nach den Daten übers Internet zur Tabelle ging. Deshalb kam schnell ein Aktualisieren auf Knopfdruck dazu, damit der Admin-Bereich nicht bei jedem Klick erst lange lädt.
Ende Januar bin ich endlich auf eine echte Datenbank (PostgreSQL) bei Neon umgestiegen, einer Firma, die sie auf einem eigenen Server aufbewahrt. So eine Datenbank weiß nichts davon, wie oft ich eine neue Version der Anwendung aufspiele, und seitdem ändert eine neue Version nur den Code, während die Daten bleiben, wo sie waren. Beim Umzug gab es noch einiges zu tun: fehlende Felder ergänzen, die Formulare besser absichern und alte Daten aufräumen. Aber die Buchungen verschwanden nicht mehr.
Was daraus folgt
Die wichtigste Erkenntnis klingt banal, hat mich aber einige Wochen gekostet: Eine Datenbank darf nicht auf derselben Festplatte wohnen wie die Anwendung, wenn diese Festplatte nur vorübergehend ist. Bei jeder Anwendung, die irgendetwas speichert, sollte man deshalb zuerst fragen, wo die Daten physisch liegen und was mit ihnen passiert, wenn die nächste Version aufgespielt wird. Die zweite Erkenntnis ist weniger offensichtlich: Wenn die Symptome seltsam sind und sich nicht auf Kommando wiederholen lassen, lohnt es sich, die Ursache außerhalb des Codes zu suchen, nämlich darin, wie und wo die Anwendung läuft.
Die dritte betrifft Menschen, nicht die Technik. Eine verlorene Buchung kann einen Schüler bedeuten, der zu einer Stunde kommt, von der ich nichts weiß, oder einen Termin, der zweimal verkauft wurde. Bei einem Kalender, den andere benutzen, ist ein Fehler beim Speichern also keine kleine Panne, sondern jemandes vergeudeter Nachmittag.
Die ganze Serie
Das ist der zweite Teil einer Serie darüber, wie Algebra i Spółka entstanden ist:
- Die erste Algebra: Flask, Templates und PHP, das ich schnell aufgab
- Buchungen, die bei jedem Deployment verschwanden
- Algebra neu gebaut: von Flask-Templates zu React und TypeScript
- Eine Preisliste in einer Datei, Premium und mein erstes Zahlungsgateway
- Aufgaben, eine Formelsammlung und Zeichnungen, die nicht stimmen wollten
Wie das Ganze heute aussieht, beschreibe ich im Beitrag Algebra i Spółka von innen.