Migrationen erzeugen: Wrapper gegen das versehentliche Löschen der Trigramm-Indizes #24
Notifications
Total Time Spent: 8 minutes
florian.wilde
8 minutes
No due date set.
Dependencies
No dependencies set.
Reference: florian.wilde/betreuungs-cockpit#24
Reference in New Issue
Block a user
Problem
prisma migrate diffkennt die Indizes ausprisma/sql/volltextsuche.sqlnicht und schreibt deshalb in jede erzeugte Migration:
Das ist bisher fünfmal passiert (Migrationen
passkey_anmeldung,zahlungsgruppe_geklaert,buchung_vertragszahlung,schreibvorlage,ansprechpartner). Jedes Mal mussten die Zeilen von Hand gestrichenwerden; jedes Mal hätte ein Vergessen die Volltextsuche stillgelegt.
Einordnung — kleiner als es klingt
scripts/update.shführt nach den Migrationenvolltextsuche.sqlerneutaus, und die Indizes stehen dort als
CREATE INDEX IF NOT EXISTS. Aufdem Server heilt sich das also von selbst. Getroffen hätte es die
Entwicklung: Dort läuft
db:sqlnicht 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>, dasmigrate differzeugt,DROP INDEX-Zeilen zu bekannten Zusatz-Indizes automatischentfernt,
Abbruch mit klarer Meldung.
Akzeptanzkriterien
Hand nachzubessern
DROP INDEX-Zeile entfernt, sagt das Skript welchedokument_absender_trgmundvorgang_titel_trgmexistierenSkript verstreut
Hinweis
Reines Werkzeug, keine Migration, keine Änderung an der Anwendung.
Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula
nachtragen.
🤖 Claude Code hat mit der Umsetzung begonnen.
feat/24-migrations-wrapperDROP INDEX-Zeilen zu bekannten Zusatz-Indizes herausnimmt und hinterher prüft, dass die Indizes noch stehen.DROP INDEXauf einen Prisma-eigenen Index, der wirklich weg soll.prisma/sql/volltextsuche.sqlheraus benannt.npm run db:migration <name>erzeugt den Ordner, schreibt die bereinigte SQL mit Kopfkommentar und sagt, was entfernt wurde.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.
🚀 Umgesetzt und nach
mainübernommen.41e33adWas es jetzt gibt
Die geschützten Indizes stehen in
GESCHUETZTE_INDIZESinscripts/migration-erzeugen.mjs. Wer inprisma/sql/einen neuen Indexanlegt, trägt ihn dort ein.
So prüfst du es
git switch main && git pullnpm run db:pruefenErwartet: „Geschuetzte Indizes stehen" mit beiden Namen.
probefeld String?an einemModell, dann
npm run db:migration -- probelaufErwartet: Eine Datei unter
prisma/migrations/…_probelauf/mit derALTER TABLE-Anweisung, ohneDROP INDEX, mit Kopfkommentar dersagt, welche zwei Anweisungen entfernt wurden.
npm run db:migration -- probelaufErwartet: 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.