Raffael SheikhandClaude Opus 4.8
9bae1702aa
Bisher reine uuid-Spalten ohne referenzielle Integritaet -> Orphan-Risiko, wenn das Ziel geloescht wird. Jetzt echte FKs mit ON DELETE SET NULL: - day_entry.blocker_id -> blocker - blocker.area_id -> area - blocker.project_id -> project Migration bereinigt vorab verwaiste IDs (UPDATE ... SET NULL), damit ADD CONSTRAINT auf Altdaten nicht bricht. Verifiziert: alle 18 Migrationen laufen gegen frische Postgres 16 durch, FKs angelegt. (todo.bezug_id / time_entry.bezug_id bleiben FK-frei: echt polymorph ueber bezug_kind project/deal/campaign — kein einzelner FK moeglich.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
9 lines
1.1 KiB
SQL
9 lines
1.1 KiB
SQL
-- Verwaiste Verweise vor dem Setzen der Foreign Keys auf NULL bereinigen — sonst
|
|
-- schlaegt ADD CONSTRAINT fehl, falls Altdaten auf geloeschte Zeilen zeigen.
|
|
UPDATE "blocker" SET "area_id" = NULL WHERE "area_id" IS NOT NULL AND "area_id" NOT IN (SELECT "id" FROM "area");--> statement-breakpoint
|
|
UPDATE "blocker" SET "project_id" = NULL WHERE "project_id" IS NOT NULL AND "project_id" NOT IN (SELECT "id" FROM "project");--> statement-breakpoint
|
|
UPDATE "day_entry" SET "blocker_id" = NULL WHERE "blocker_id" IS NOT NULL AND "blocker_id" NOT IN (SELECT "id" FROM "blocker");--> statement-breakpoint
|
|
ALTER TABLE "blocker" ADD CONSTRAINT "blocker_area_id_area_id_fk" FOREIGN KEY ("area_id") REFERENCES "public"."area"("id") ON DELETE set null ON UPDATE no action;--> statement-breakpoint
|
|
ALTER TABLE "blocker" ADD CONSTRAINT "blocker_project_id_project_id_fk" FOREIGN KEY ("project_id") REFERENCES "public"."project"("id") ON DELETE set null ON UPDATE no action;--> statement-breakpoint
|
|
ALTER TABLE "day_entry" ADD CONSTRAINT "day_entry_blocker_id_blocker_id_fk" FOREIGN KEY ("blocker_id") REFERENCES "public"."blocker"("id") ON DELETE set null ON UPDATE no action;
|