Florian Wilde
02ca74e661
Die Zuordnung lief allein ueber vorgesetzterExterneId, und die ist nur
innerhalb einer Verzeichnisquelle eindeutig: eine von Hand angelegte Person
konnte keinen Vorgesetzten haben, und {{vorgesetzter_sam}} blieb im
Onboarding-Befehl leer -- genau dort, wo er gebraucht wird.
Entschieden fuer eine eigene Selbstbeziehung vorgesetzterId. Die befuerchteten
"zwei Wege zur selben Auskunft" entstehen nicht, weil der Abgleich sie
mitschreibt: vorgesetzterExterneId ist jetzt wie abteilung nur der rohe Wert
des Verzeichnisses, gelesen wird allein vorgesetzterId. Die Alternative haette
manuellen Personen eine erfundene externeId geben muessen, und externeId heisst
"objectGUID aus dem Verzeichnis".
Liefert das Verzeichnis keinen manager, bleibt eine von Hand gesetzte Zuordnung
stehen -- geleert wird nur, was das Verzeichnis selbst gesetzt hatte.
Die Migration fuehrt bestehende Daten nach. Ohne das waere die Auskunft nach
dem Einspielen bei jeder Verzeichnis-Person still leer gewesen, bis der
naechste Abgleich laeuft. An einem nachgebauten Vor-Zustand gefahren.
Drei Grenzen, drei Stellen: der zusammengesetzte Fremdschluessel haelt die
Mandantengrenze, ein CHECK die kuerzeste Schleife, und der Dienst laeuft die
Kette hinauf fuer laengere.
Im gebauten Stand durchgeklickt: speichern, neu laden, Wert steht, entfernen,
390 px ohne horizontales Scrollen. Gegenprobe am Abgleich gefahren.
Closes #31
63 lines
3.2 KiB
SQL
63 lines
3.2 KiB
SQL
-- ---------------------------------------------------------------------------
|
||
-- HANDGESCHRIEBEN. Prisma erzeugt hier zusaetzlich Loeschbefehle fuer die
|
||
-- zusammengesetzten Fremdschluessel (Mandantengrenze), die Trigramm-Indizes
|
||
-- (Archivsuche), die partiellen eindeutigen Indizes und die Trigger auf
|
||
-- veroeffentlichten Versionen: es kennt sie nicht, weil sie sich im Schema nicht
|
||
-- ausdruecken lassen. Diese Loeschbefehle sind bewusst gestrichen.
|
||
--
|
||
-- tests/datenbankregeln.test.ts prueft, dass alle diese Objekte vorhanden sind –
|
||
-- ein versehentlich stehengelassener Loeschbefehl faellt dort sofort auf.
|
||
-- ---------------------------------------------------------------------------
|
||
|
||
-- Vorgesetzter auch fuer von Hand angelegte Personen (#020).
|
||
--
|
||
-- Bisher lief die Auskunft allein ueber `vorgesetzterExterneId`, und die ist nur
|
||
-- innerhalb einer Verzeichnisquelle eindeutig: eine Person ohne Quelle konnte
|
||
-- keinen Vorgesetzten haben, {{vorgesetzter_sam}} blieb dort immer leer.
|
||
ALTER TABLE "Mitarbeiter"
|
||
ADD COLUMN "vorgesetzterId" TEXT;
|
||
|
||
CREATE INDEX "Mitarbeiter_vorgesetzterId_idx" ON "Mitarbeiter"("vorgesetzterId");
|
||
|
||
ALTER TABLE "Mitarbeiter"
|
||
ADD CONSTRAINT "Mitarbeiter_vorgesetzterId_fkey"
|
||
FOREIGN KEY ("vorgesetzterId") REFERENCES "Mitarbeiter" ("id")
|
||
ON DELETE RESTRICT ON UPDATE CASCADE;
|
||
|
||
-- Die Mandantengrenze, wie bei Lauf und Geraet: der Vorgesetzte gehoert zum
|
||
-- selben Kunden. MATCH SIMPLE ist richtig — ist die Spalte NULL, greift der
|
||
-- Fremdschluessel nicht, eine Person ohne Vorgesetzten bleibt also erlaubt.
|
||
ALTER TABLE "Mitarbeiter"
|
||
ADD CONSTRAINT "Mitarbeiter_vorgesetzter_gleicher_kunde"
|
||
FOREIGN KEY ("vorgesetzterId", "kundeId") REFERENCES "Mitarbeiter" ("id", "kundeId")
|
||
ON DELETE RESTRICT ON UPDATE CASCADE;
|
||
|
||
-- Niemand ist sein eigener Vorgesetzter. Das ist die kuerzeste Schleife und die
|
||
-- einzige, die sich ohne Rekursion abfangen laesst; laengere haelt der Dienst
|
||
-- auf (siehe mitarbeiter.ts, vorgesetztenSetzen).
|
||
ALTER TABLE "Mitarbeiter"
|
||
ADD CONSTRAINT "Mitarbeiter_vorgesetzter_nicht_selbst"
|
||
CHECK ("vorgesetzterId" IS NULL OR "vorgesetzterId" <> "id");
|
||
|
||
-- Nachfuehrung fuer bestehende Installationen.
|
||
--
|
||
-- Ohne sie waere `{{vorgesetzter_sam}}` nach dieser Migration bei **jeder**
|
||
-- Person aus dem Verzeichnis leer, bis der naechste Abgleich laeuft -- und zwar
|
||
-- still: die Auskunft lief bisher allein ueber `vorgesetzterExterneId`, der neue
|
||
-- Leseweg nimmt nur `vorgesetzterId`. Dieselbe Falle wie beim Seed-Schluessel
|
||
-- in #021: ein Umstieg, der die vorhandenen Daten nicht mitnimmt.
|
||
--
|
||
-- Die Zuordnung laeuft ueber die `externeId` **derselben** Quelle, genau wie der
|
||
-- alte Leseweg: die Kennung ist nur dort eindeutig.
|
||
UPDATE "Mitarbeiter" AS person
|
||
SET "vorgesetzterId" = chef."id"
|
||
FROM "Mitarbeiter" AS chef
|
||
WHERE person."vorgesetzterExterneId" IS NOT NULL
|
||
AND person."quelleId" IS NOT NULL
|
||
AND chef."quelleId" = person."quelleId"
|
||
AND chef."externeId" = person."vorgesetzterExterneId"
|
||
-- Die Mandantengrenze gilt auch hier; stand je eine Zuordnung ueber Kunden
|
||
-- hinweg in den Daten, bliebe sie leer statt den Fremdschluessel zu brechen.
|
||
AND chef."kundeId" = person."kundeId"
|
||
AND chef."id" <> person."id";
|