feat(seed): sieben Vorlagen, Beispielbestand und Demo-Kunden (#33)
This commit was merged in pull request #33.
This commit is contained in:
@@ -331,6 +331,41 @@ hinter einem Reverse Proxy kommen sich sonst in die Quere. Der Zeitplan nimmt
|
||||
ausdruecklich **keine** eigene Sperre — sie traege einen anderen Schluessel und
|
||||
liefe an der des Dienstes vorbei.
|
||||
|
||||
## 5h. Der Seed: einrichten, nicht aufraeumen
|
||||
|
||||
Die sieben Vorlagen stehen als **JSON im Austauschformat** unter
|
||||
`prisma/seed-daten/vorlagen/` und nicht als TypeScript-Literale. Damit prueft sie
|
||||
dasselbe Zod-Schema, das auch Import, Export und Editor benutzen: eine
|
||||
Seed-Vorlage ist genau das, was ein Redakteur einspielen koennte, und ein Fehler
|
||||
faellt beim Einrichten auf statt im ersten Lauf.
|
||||
|
||||
Angelegt werden sie **nicht** ueber `vorlageImportieren`. Der Import erzeugt
|
||||
absichtlich einen Entwurf und schreibt einen Protokolleintrag mit dem handelnden
|
||||
Menschen; der Seed hat keinen Menschen und braucht veroeffentlichte Versionen,
|
||||
weil sich sonst kein Lauf starten liesse. Er geht trotzdem denselben Weg wie ein
|
||||
Redakteur — **erst Entwurf, dann veroeffentlichen**: die Trigger aus #010
|
||||
verbieten jedes Schreiben an Abschnitten, Variablen und Schritten einer
|
||||
veroeffentlichten Version. Eine Version gleich als `VEROEFFENTLICHT` anzulegen und
|
||||
danach zu fuellen scheitert an der Datenbank, und das ist richtig so.
|
||||
|
||||
**Der Seed richtet ein, er raeumt nicht auf.** Jede Zeile hat einen sprechenden
|
||||
Schluessel — die Vorlage ihren Namen, die Abteilung `(kundeId, name)`, die Person
|
||||
ihren UPN, das Geraet seinen `tagCode` —, und was es schon gibt, bleibt
|
||||
unberuehrt. Kein `upsert` mit gefuelltem `update`: eine im Betrieb geaenderte
|
||||
Ziel-OU, eine bearbeitete Vorlage und ein umgeschalteter Betriebsmodus ueberstehen
|
||||
jeden weiteren Lauf. Zweimal hintereinander aufgerufen aendert der zweite Lauf
|
||||
nichts, und `tests/seed.test.ts` haelt das fest.
|
||||
|
||||
Im Modus DIENSTLEISTUNG haengt der Beispielbestand an der **Musterfirma** und nicht
|
||||
an der eigenen Organisation: der Auftrag verlangt, dass `LZ-7K3F9Q` dort auf
|
||||
`MUS-PC-001` fuehrt. Ein Tag-Code gehoert genau einem Geraet, beides zugleich
|
||||
ginge also ohnehin nicht — „erzeugt **stattdessen**“.
|
||||
|
||||
Die Tag-Codes der Beispielgeraete sind **fest** und nicht gezogen. Ein Seed, der
|
||||
jedes Mal fuenf neue Codes zieht, waere nicht idempotent: beim dritten Lauf laegen
|
||||
fuenfzehn Aufkleber im Stapel. Weil ein `tagCode` global eindeutig ist und nie
|
||||
wiederverwendet wird, bekommt jeder Demo-Kunde seinen eigenen Satz.
|
||||
|
||||
## 6. Betrieb: zwei Wege, eine Regel
|
||||
|
||||
Die Datenbank ist auf beiden Wegen von außen nicht erreichbar:
|
||||
|
||||
Reference in New Issue
Block a user