Migrationen erzeugen: Wrapper gegen das versehentliche Löschen der Trigramm-Indizes #24

Closed
opened 2026-08-23 16:55:49 +00:00 by florian.wilde · 2 comments
Owner

Problem

prisma migrate diff kennt die Indizes aus prisma/sql/volltextsuche.sql
nicht und schreibt deshalb in jede erzeugte Migration:

DROP INDEX "dokument_absender_trgm";
DROP INDEX "vorgang_titel_trgm";

Das ist bisher fünfmal passiert (Migrationen passkey_anmeldung,
zahlungsgruppe_geklaert, buchung_vertragszahlung, schreibvorlage,
ansprechpartner). Jedes Mal mussten die Zeilen von Hand gestrichen
werden; jedes Mal hätte ein Vergessen die Volltextsuche stillgelegt.

Einordnung — kleiner als es klingt

scripts/update.sh führt nach den Migrationen volltextsuche.sql erneut
aus, und die Indizes stehen dort als CREATE INDEX IF NOT EXISTS. Auf
dem Server heilt sich das also von selbst.
Getroffen hätte es die
Entwicklung: Dort läuft db:sql nicht automatisch nach einer Migration,
und die Suche wäre still langsam geworden, ohne dass etwas fehlschlägt.

Es ist also Bequemlichkeit und Fehlervermeidung, keine Rettung.

Was ich will

Ein npm run db:migration <name>, das

  • die Migration mit migrate diff erzeugt,
  • die DROP INDEX-Zeilen zu bekannten Zusatz-Indizes automatisch
    entfernt,
  • einen Kopfkommentar einsetzt, was entfernt wurde,
  • und nach dem Anwenden prüft, ob beide Indizes noch stehen — sonst
    Abbruch mit klarer Meldung.

Akzeptanzkriterien

  • Eine neue Migration lässt sich mit einem Befehl erzeugen, ohne von
    Hand nachzubessern
  • Wird eine DROP INDEX-Zeile entfernt, sagt das Skript welche
  • Nach dem Anwenden wird geprüft, dass dokument_absender_trgm und
    vorgang_titel_trgm existieren
  • Die Liste der geschützten Indizes steht an einer Stelle, nicht im
    Skript verstreut

Hinweis

Reines Werkzeug, keine Migration, keine Änderung an der Anwendung.

Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula
nachtragen.

## Problem `prisma migrate diff` kennt die Indizes aus `prisma/sql/volltextsuche.sql` nicht und schreibt deshalb in **jede** erzeugte Migration: ```sql DROP INDEX "dokument_absender_trgm"; DROP INDEX "vorgang_titel_trgm"; ``` Das ist bisher fünfmal passiert (Migrationen `passkey_anmeldung`, `zahlungsgruppe_geklaert`, `buchung_vertragszahlung`, `schreibvorlage`, `ansprechpartner`). Jedes Mal mussten die Zeilen von Hand gestrichen werden; jedes Mal hätte ein Vergessen die Volltextsuche stillgelegt. ## Einordnung — kleiner als es klingt `scripts/update.sh` führt nach den Migrationen `volltextsuche.sql` erneut aus, und die Indizes stehen dort als `CREATE INDEX IF NOT EXISTS`. **Auf dem Server heilt sich das also von selbst.** Getroffen hätte es die Entwicklung: Dort läuft `db:sql` nicht automatisch nach einer Migration, und die Suche wäre still langsam geworden, ohne dass etwas fehlschlägt. Es ist also Bequemlichkeit und Fehlervermeidung, keine Rettung. ## Was ich will Ein `npm run db:migration <name>`, das - die Migration mit `migrate diff` erzeugt, - die `DROP INDEX`-Zeilen zu bekannten Zusatz-Indizes automatisch entfernt, - einen Kopfkommentar einsetzt, was entfernt wurde, - und nach dem Anwenden prüft, ob beide Indizes noch stehen — sonst Abbruch mit klarer Meldung. ## Akzeptanzkriterien - [ ] Eine neue Migration lässt sich mit einem Befehl erzeugen, ohne von Hand nachzubessern - [ ] Wird eine `DROP INDEX`-Zeile entfernt, sagt das Skript welche - [ ] Nach dem Anwenden wird geprüft, dass `dokument_absender_trgm` und `vorgang_titel_trgm` existieren - [ ] Die Liste der geschützten Indizes steht an einer Stelle, nicht im Skript verstreut ## Hinweis Reines Werkzeug, keine Migration, keine Änderung an der Anwendung. _Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula nachtragen._
florian.wilde added the in-arbeit label 2026-08-23 17:16:27 +00:00
florian.wilde started working 2026-08-23 17:16:55 +00:00
Author
Owner

🤖 Claude Code hat mit der Umsetzung begonnen.

  • Branch: feat/24-migrations-wrapper
  • Verstanden als: Ein Befehl, der eine Migration erzeugt, die DROP INDEX-Zeilen zu bekannten Zusatz-Indizes herausnimmt und hinterher prüft, dass die Indizes noch stehen.
  • Geplantes Vorgehen:
    • Das Entfernen der Zeilen als reine Funktion mit Tests — sie muss den Index treffen und alles andere in Ruhe lassen, auch ein DROP INDEX auf einen Prisma-eigenen Index, der wirklich weg soll.
    • Die Liste der geschützten Indizes an einer Stelle, aus prisma/sql/volltextsuche.sql heraus benannt.
    • npm run db:migration <name> erzeugt den Ordner, schreibt die bereinigte SQL mit Kopfkommentar und sagt, was entfernt wurde.
    • Nach dem Anwenden ein Prüfschritt gegen die Datenbank: fehlt ein Index, bricht er mit klarer Meldung ab.

Ohne Freigabeschritt: Auf Zuruf im Chat werden diese acht Issues (#21–#28) nacheinander umgesetzt und direkt gemergt. Die Testanleitung steht trotzdem im Abschlusskommentar.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `feat/24-migrations-wrapper` - Verstanden als: Ein Befehl, der eine Migration erzeugt, die `DROP INDEX`-Zeilen zu bekannten Zusatz-Indizes herausnimmt und hinterher prüft, dass die Indizes noch stehen. - Geplantes Vorgehen: - Das Entfernen der Zeilen als reine Funktion mit Tests — sie muss den Index treffen und alles andere in Ruhe lassen, auch ein `DROP INDEX` auf einen Prisma-eigenen Index, der wirklich weg soll. - Die Liste der geschützten Indizes an einer Stelle, aus `prisma/sql/volltextsuche.sql` heraus benannt. - `npm run db:migration <name>` erzeugt den Ordner, schreibt die bereinigte SQL mit Kopfkommentar und sagt, was entfernt wurde. - Nach dem Anwenden ein Prüfschritt gegen die Datenbank: fehlt ein Index, bricht er mit klarer Meldung ab. Ohne Freigabeschritt: Auf Zuruf im Chat werden diese acht Issues (#21–#28) nacheinander umgesetzt und direkt gemergt. Die Testanleitung steht trotzdem im Abschlusskommentar. Zeiterfassung läuft.
florian.wilde worked for 8 minutes 2026-08-23 17:25:19 +00:00
Author
Owner

🚀 Umgesetzt und nach main übernommen.

  • Merge-Commit: 41e33ad
  • Pull Request: #29 (gemergt)
  • Gesamtaufwand: 00:08

Was es jetzt gibt

npm run db:migration -- <name>              erzeugen, nicht anwenden
npm run db:migration -- <name> --anwenden   erzeugen und anwenden
npm run db:pruefen                          nur prüfen

Die geschützten Indizes stehen in GESCHUETZTE_INDIZES in
scripts/migration-erzeugen.mjs. Wer in prisma/sql/ einen neuen Index
anlegt, trägt ihn dort ein.

So prüfst du es

  1. git switch main && git pull
  2. npm run db:pruefen
    Erwartet: „Geschuetzte Indizes stehen" mit beiden Namen.
  3. Eine Zeile ins Schema einfügen, etwa probefeld String? an einem
    Modell, dann npm run db:migration -- probelauf
    Erwartet: Eine Datei unter prisma/migrations/…_probelauf/ mit der
    ALTER TABLE-Anweisung, ohne DROP INDEX, mit Kopfkommentar der
    sagt, welche zwei Anweisungen entfernt wurden.
  4. Die Schemazeile wieder entfernen, den Ordner löschen, dann erneut
    npm run db:migration -- probelauf
    Erwartet: Abbruch mit „Es gibt nichts zu migrieren", kein neuer
    Ordner.

Beim Bauen gefunden: Im Fall aus Schritt 4 hat das Skript zunächst
eine leere Migration angelegt — nur Kopfkommentar, keine Anweisung. Eine
leere Migration in der Historie ist schlimmer als keine, weil sie als
angewendet gilt. Behoben, mit Test.

Weder Changelog-Eintrag noch Versionsnummer: An der Anwendung ändert
sich nichts.

Ohne Freigabeschritt gemergt — auf ausdrücklichen Zuruf im Chat für die
Reihe #21–#28.

🚀 **Umgesetzt und nach `main` übernommen.** <!-- claude-status branch: feat/24-migrations-wrapper merge: 41e33ad pr: 29 zeit_sekunden: 504 --> - Merge-Commit: `41e33ad` - Pull Request: #29 (gemergt) - Gesamtaufwand: 00:08 **Was es jetzt gibt** ``` npm run db:migration -- <name> erzeugen, nicht anwenden npm run db:migration -- <name> --anwenden erzeugen und anwenden npm run db:pruefen nur prüfen ``` Die geschützten Indizes stehen in `GESCHUETZTE_INDIZES` in `scripts/migration-erzeugen.mjs`. Wer in `prisma/sql/` einen neuen Index anlegt, trägt ihn dort ein. **So prüfst du es** 1. `git switch main && git pull` 2. `npm run db:pruefen` Erwartet: „Geschuetzte Indizes stehen" mit beiden Namen. 3. Eine Zeile ins Schema einfügen, etwa `probefeld String?` an einem Modell, dann `npm run db:migration -- probelauf` Erwartet: Eine Datei unter `prisma/migrations/…_probelauf/` mit der `ALTER TABLE`-Anweisung, ohne `DROP INDEX`, mit Kopfkommentar der sagt, welche zwei Anweisungen entfernt wurden. 4. Die Schemazeile wieder entfernen, den Ordner löschen, dann erneut `npm run db:migration -- probelauf` Erwartet: Abbruch mit „Es gibt nichts zu migrieren", **kein** neuer Ordner. **Beim Bauen gefunden:** Im Fall aus Schritt 4 hat das Skript zunächst eine leere Migration angelegt — nur Kopfkommentar, keine Anweisung. Eine leere Migration in der Historie ist schlimmer als keine, weil sie als angewendet gilt. Behoben, mit Test. Weder Changelog-Eintrag noch Versionsnummer: An der Anwendung ändert sich nichts. Ohne Freigabeschritt gemergt — auf ausdrücklichen Zuruf im Chat für die Reihe #21–#28.
florian.wilde removed the in-arbeit label 2026-08-23 17:26:37 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Total Time Spent: 8 minutes
florian.wilde
8 minutes
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#24