npm run db:migrate ist interaktiv und damit unbrauchbar #27

New Issue

2026-08-23T16:56:43Z

florian.wilde commented

2026-08-23 16:56:43 +00:00

Problem

npm run db:migrate ruft prisma migrate dev auf. Das ist ein
interaktiver Befehl: Er fragt nach einem Namen, will bei Abweichungen
bestätigt bekommen und bietet an, die Datenbank zurückzusetzen.

In einer nicht-interaktiven Umgebung — Skript, CI, Claude Code — bleibt
er hängen oder bricht ab. Praktisch benutzt wurde deshalb durchweg
npx prisma migrate deploy, also npm run db:deploy.

Was ich will

Klarheit darüber, welcher Befehl wofür gedacht ist:

Entweder db:migrate auf einen nicht-interaktiven Ablauf umstellen
oder es beim interaktiven Befehl belassen und im README benennen, dass
er nur am Terminal funktioniert, während db:deploy der Weg für
Skripte und Server ist

Akzeptanzkriterien

Aus dem Skriptnamen oder der Dokumentation geht hervor, welcher
Befehl interaktiv ist und welcher nicht
Ein Ablauf, der ohne Rückfragen durchläuft, ist benannt
Die Anleitung in docs/INSTALLATION.md nennt für das Update
denselben Befehl, den scripts/update.sh verwendet

Hinweis

Hängt an #24 — wenn der Migrations-Wrapper kommt, sollte er sich in
dieselbe Ordnung einfügen.

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

## Problem `npm run db:migrate` ruft `prisma migrate dev` auf. Das ist ein interaktiver Befehl: Er fragt nach einem Namen, will bei Abweichungen bestätigt bekommen und bietet an, die Datenbank zurückzusetzen. In einer nicht-interaktiven Umgebung — Skript, CI, Claude Code — bleibt er hängen oder bricht ab. Praktisch benutzt wurde deshalb durchweg `npx prisma migrate deploy`, also `npm run db:deploy`. ## Was ich will Klarheit darüber, welcher Befehl wofür gedacht ist: - Entweder `db:migrate` auf einen nicht-interaktiven Ablauf umstellen - oder es beim interaktiven Befehl belassen und im README benennen, dass er nur am Terminal funktioniert, während `db:deploy` der Weg für Skripte und Server ist ## Akzeptanzkriterien - [ ] Aus dem Skriptnamen oder der Dokumentation geht hervor, welcher Befehl interaktiv ist und welcher nicht - [ ] Ein Ablauf, der ohne Rückfragen durchläuft, ist benannt - [ ] Die Anleitung in `docs/INSTALLATION.md` nennt für das Update denselben Befehl, den `scripts/update.sh` verwendet ## Hinweis Hängt an #24 — wenn der Migrations-Wrapper kommt, sollte er sich in dieselbe Ordnung einfügen. _Angelegt auf Zuruf im Chat, nicht aus dem Dashboard — bitte in Nebula nachtragen._

florian.wilde added the in-arbeit label 2026-08-23 17:32:47 +00:00

florian.wilde started working 2026-08-23 17:33:03 +00:00

florian.wilde commented

2026-08-23 17:33:23 +00:00

🤖 Claude Code hat mit der Umsetzung begonnen.

Branch: fix/27-db-befehle
Verstanden als: Aus den Skriptnamen geht nicht hervor, welcher Datenbankbefehl Rückfragen stellt und welcher nicht — das kostet jedes Mal einen Fehlversuch.
Geplantes Vorgehen:
- npm run setup verweist auf ein Skript db:sql, das es gibt; die README nennt an derselben Stelle aber npx prisma migrate dev --name fundament. Beides nebeneinander ist verwirrend, ich vereinheitliche es.
- Die drei Wege klar benennen: Ersteinrichtung, Schemaänderung während der Entwicklung (jetzt über den Wrapper aus #24), Anwenden auf einem bestehenden Bestand.
- Ein Abschnitt in der README, der die Datenbankbefehle in einer Tabelle zeigt — mit der Angabe, welcher interaktiv ist.
- db:migrate bleibt bestehen (migrate dev hat seinen Platz am Terminal), bekommt aber im Skriptnamen und in der Dokumentation den Zusatz, dass er Rückfragen stellt.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `fix/27-db-befehle` - Verstanden als: Aus den Skriptnamen geht nicht hervor, welcher Datenbankbefehl Rückfragen stellt und welcher nicht — das kostet jedes Mal einen Fehlversuch. - Geplantes Vorgehen: - `npm run setup` verweist auf ein Skript `db:sql`, das es gibt; die README nennt an derselben Stelle aber `npx prisma migrate dev --name fundament`. Beides nebeneinander ist verwirrend, ich vereinheitliche es. - Die drei Wege klar benennen: Ersteinrichtung, Schemaänderung während der Entwicklung (jetzt über den Wrapper aus #24), Anwenden auf einem bestehenden Bestand. - Ein Abschnitt in der README, der die Datenbankbefehle in einer Tabelle zeigt — mit der Angabe, welcher interaktiv ist. - `db:migrate` bleibt bestehen (`migrate dev` hat seinen Platz am Terminal), bekommt aber im Skriptnamen und in der Dokumentation den Zusatz, dass er Rückfragen stellt. Zeiterfassung läuft.

florian.wilde worked for 2 minutes

2026-08-23 17:35:30 +00:00

florian.wilde referenced this issue from a commit

2026-08-23 17:35:43 +00:00

Datenbankbefehle benennen, welcher Rueckfragen stellt

florian.wilde referenced a pull request that will close this issue

2026-08-23 17:35:55 +00:00

Fix #27: Datenbankbefehle benennen, welcher Rückfragen stellt #31

florian.wilde closed this issue

2026-08-23 17:36:07 +00:00

florian.wilde referenced this issue from a commit

2026-08-23 17:36:08 +00:00

Merge #31: Datenbankbefehle benennen, welcher Rueckfragen stellt

florian.wilde commented

2026-08-23 17:36:41 +00:00

🚀 Umgesetzt und nach main übernommen.

Merge-Commit: 5022a97
Pull Request: #31 (gemergt)
Gesamtaufwand: 00:03

Was geändert wurde — alles in der README:

Neuer Abschnitt Die Datenbankbefehle unter Entwicklung: alle sieben Befehle mit Zweck und Spalte „Rückfragen?". Genau einer steht dort auf ja.
Der übliche Weg für eine Schemaänderung als Dreizeiler, über den Wrapper aus #24.
Die Ersteinrichtung rief npx prisma migrate dev --name fundament auf, obwohl es dafür npm run setup gibt — das war der Ausgangspunkt der Verwirrung.
Der Hinweis unter Betriebswissen, die SQL-Skripte seien von Hand anzustoßen, galt nur für die Ersteinrichtung; beim Aktualisieren erledigt update.sh das mit. Steht jetzt dabei.

db:migrate bleibt bestehen — der interaktive Ablauf hat seinen Platz, er ist nur nicht mehr der Standardweg.

docs/INSTALLATION.md brauchte keine Änderung: Sie nennt für den Server bereits denselben Befehl wie scripts/update.sh.

So prüfst du es

git switch main && git pull
README öffnen, Abschnitt Entwicklung → Die Datenbankbefehle.
Erwartet: Tabelle mit sieben Zeilen, nur db:migrate mit ja.
Im Schnellstart nachsehen: Schritt 3 nennt npm run setup, nicht mehr migrate dev.

Weder Changelog noch Version — reine Dokumentation.

🚀 **Umgesetzt und nach `main` übernommen.**  - Merge-Commit: `5022a97` - Pull Request: #31 (gemergt) - Gesamtaufwand: 00:03 **Was geändert wurde** — alles in der README: - Neuer Abschnitt **Die Datenbankbefehle** unter *Entwicklung*: alle sieben Befehle mit Zweck und Spalte „Rückfragen?". Genau einer steht dort auf **ja**. - Der übliche Weg für eine Schemaänderung als Dreizeiler, über den Wrapper aus #24. - Die Ersteinrichtung rief `npx prisma migrate dev --name fundament` auf, obwohl es dafür `npm run setup` gibt — das war der Ausgangspunkt der Verwirrung. - Der Hinweis unter *Betriebswissen*, die SQL-Skripte seien von Hand anzustoßen, galt nur für die Ersteinrichtung; beim Aktualisieren erledigt `update.sh` das mit. Steht jetzt dabei. `db:migrate` bleibt bestehen — der interaktive Ablauf hat seinen Platz, er ist nur nicht mehr der Standardweg. `docs/INSTALLATION.md` brauchte keine Änderung: Sie nennt für den Server bereits denselben Befehl wie `scripts/update.sh`. **So prüfst du es** 1. `git switch main && git pull` 2. README öffnen, Abschnitt *Entwicklung → Die Datenbankbefehle*. Erwartet: Tabelle mit sieben Zeilen, nur `db:migrate` mit **ja**. 3. Im Schnellstart nachsehen: Schritt 3 nennt `npm run setup`, nicht mehr `migrate dev`. Weder Changelog noch Version — reine Dokumentation.

florian.wilde removed the in-arbeit label 2026-08-23 17:36:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Total Time Spent: 2 minutes

florian.wilde

2 minutes

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#27