Datenbanken und Schemata

Worum es geht

Eine Installation hat mehr als eine Datenbank, und nicht jede gehört demselben Modul. Wer welche Tabellen anlegt und anhebt, hängt davon ab, wie die Module zusammengesteckt sind.

Die Landkarte

Welche Datenbanken es gibt

EingebettetGetrennt

Wann: CDMS und CIAS laufen im selben Prozess.

flowchart TB
    P["Ein Prozess<br/>CDMS + CIAS"]
    P --> S[("System-Datenbank<br/>System-Modelle von CDMS<br/>+ alle CIAS-Tabellen")]
    P --> T1[("Mandanten-DB nordbau")]
    P --> T2[("Mandanten-DB acme")]

Ergebnis: Eine System-Datenbank für beide Module. cias_tenant listet alle Mandanten auf und kann deshalb nicht einmal pro Mandant existieren.

Wann: CIAS ist ein eigener Dienst.

flowchart TB
    D1["CDMS-Dienst"]
    D2["CIAS-Dienst"]
    D1 --> S[("System-Datenbank<br/>System-Modelle von CDMS")]
    D1 --> T1[("Mandanten-DB nordbau")]
    D1 --> T2[("Mandanten-DB acme")]
    D2 --> C[("CIAS-Datenbank<br/>alle CIAS-Tabellen")]

Ergebnis: Zwei getrennte Welten. Eine Installation darf beide auf dieselbe Datenbank zeigen lassen — es sind genau die Tabellen, die eingebettet nebeneinanderliegen. Nötig ist das nicht.

Welche Daten in welcher Datenbank landen, entscheidet auf der CDMS-Seite die Ebene des Modells, siehe Welche Datenbank? Das Persistenzziel.

Wer welche Tabellen hält

Datenbank	Wie viele	Wer schreibt hinein	Beispiele
System-Datenbank	eine	CDMS mit seinen System-Modellen; eingebettet zusätzlich CIAS	Stammdaten, die für alle Kunden gelten
Mandanten-Datenbank	eine je Mandant, nur in `MULTI`	nur CDMS	Mandanten- und Benutzer-Modelle, dazu die Revisionen
CIAS-Datenbank	eine, nur getrennt	nur CIAS	Mandanten, Benutzer, Rollenkatalog, Gruppen, Registrierungen, Mailvorlagen, Audit

In SINGLE gibt es nur eine Datenbank. System- und Mandanten-Modelle liegen dann nebeneinander darin, und eine Ebene weniger ist zu beachten.

Wer migriert, und wann

Migrieren heißt: die Tabellen einer Datenbank auf den Stand bringen, den die Anwendung erwartet. Die beiden Module tun das auf verschiedenen Wegen, und das ist kein Zufall: CDMS hat je Kunde eine Datenbank, die es erst beim ersten Zugriff sieht; CIAS hat genau eine und kennt sie beim Start.

	CDMS	CIAS mit Starter	CIAS ohne Starter
Wann	beim ersten Zugriff auf ein Ziel nach dem Start, und bei der Einrichtung eines neuen Mandanten	während der Prozess hochfährt, bevor Hibernate die Tabellen ansieht	wie beim Gastgeber, also mit dessen System-Datenbank
Wie	Standard: Hibernate ergänzt, was fehlt. Wahlweise versionierte Skripte	ein eigener Migrationslauf je Modul, jeder mit eigener Historientabelle	gar nicht eigenständig: Der Gastgeber meldet die CIAS-Entitäten bei seiner Persistenz an
Wo die Skripte liegen	zwei Orte, einer für die System-Datenbank und einer für die Mandanten-Datenbanken	ein Ort je Modul, ausdrücklich aufgezählt, nie gesucht	keine — es gibt keinen CIAS-Migrationslauf in diesem Prozess
Was Hibernate danach tut	prüft, wenn Skripte das Schema führen; ergänzt sonst selbst	prüft nur noch, ob Tabellen und Entitäten zusammenpassen	wie beim Gastgeber
Ziel	System-Datenbank und jede Mandanten-Datenbank einzeln	die eine Datenbank, die CIAS hat	die System-Datenbank des Gastgebers

Warum CIAS je Modul eine eigene Historie führt

Jedes CIAS-Modul ist ein eigenes Repository und wird für sich veröffentlicht. Also fängt jedes seine Zählung bei V1__ an. Sechs Module mit sechs Skripten „Version 1“ passen nicht in eine gemeinsame Historientabelle — Flyway würde sechs Migrationen finden, die alle Version eins zu sein behaupten.

Der Migrationslauf mit Starter

1

CIAS
liest die Liste der Orte, einen je Modul, aus der Konfiguration

Kein Suchen im Klassenpfad. Ein Ort, den die Installation nennt und der keine Skripte enthält, bricht den Start ab — ein Tippfehler würde sonst still nichts migrieren.
2

CIAS
leitet aus jedem Ort den Namen seiner Historientabelle ab, etwa flyway_schema_history_cias_tenancy

Zwei Orte, die denselben Namen ergäben, brechen den Start ab. Sie teilten sich sonst eine Historie, und das zweite Modul hielte seine eigene V1__ für schon erledigt.
3

CIAS→Datenbank
führt je Ort einen Lauf aus, mit Grundlinie Version 0

Fehlt die Historientabelle eines Moduls, hat es hier noch nie gelaufen — egal, was sonst im Schema steht. Die übliche Grundlinie „Version 1“ wäre hier falsch: Das Schema ist nach dem ersten Modul nie mehr leer, und das zweite würde seine V1__ überspringen.
4

CIAS
erst danach baut Hibernate seine Objekte

Ergebnis: Jedes Modul hat seine eigene Historie und kann für sich weiterwandern.

Die Tabellen liegen alle in derselben Datenbank, nebeneinander und neben der Historientabelle von CDMS, falls eine Installation sich eine Datenbank teilt. Deshalb ist der Namenspräfix einstellbar.

Der ganze Lauf hängt an drei Bedingungen: Flyway muss im Klassenpfad liegen, es muss eine Datenbank geben, und codamai.cias.migration.enabled muss auf true stehen. Fehlt eine davon, passiert nichts.

Und wenn der Gastgeber seine Datenbanken selbst verteilt?

Ein Gastgeber mit CDMS-Persistenz, etwa das Hub-Backend, hat nicht eine Datenbank, sondern eine je Einheit (System, Mandanten). Er baut das Schema einer Einheit auf, wenn sie zum ersten Mal gebraucht wird. Die zweite Bedingung oben trifft dort nicht zu, der Lauf startet also nicht von allein.

Stattdessen hängt sich CIAS in diesen Schritt des Gastgebers:

In der Einheit, die die CIAS-Tabellen hält, laufen zuerst die CIAS-Skripte, Modul für Modul, jedes mit eigener Historie wie oben.
Danach läuft die Migration des Gastgebers.
Erst dann baut Hibernate seine Objekte.

Damit Hibernate die CIAS-Tabellen kennt, meldet der Gastgeber die CIAS-Entitäten zusätzlich bei seiner Persistenz an — eine Beitragsliste mit Geltungsbereich SYSTEM. Abschalten lässt sich der CIAS-Lauf mit CIAS_MIGRATION=false.

Der Geltungsbereich sagt dabei nur, welche Einheit die Tabellen hält:

Geltungsbereich	Wohin die Tabellen gehören
`SYSTEM`	in die System-Einheit; in einer Installation ohne Mandantentrennung ist das die einzige
`TENANT`	in jede Mandanten-Einheit, einmal je Mandant

CIAS-Tabellen sind immer SYSTEM. Eine Tabelle, die alle Mandanten auflistet, kann nicht einmal pro Mandant existieren.

Die Reihenfolge beim Start

Was vor der ersten Anfrage passiert

1

CIAS→Datenbank
die CIAS-Tabellen, Modul für Modul

Hibernate wartet ausdrücklich darauf. Ohne das könnte die Prüfung gegen Tabellen laufen, die gerade erst entstehen sollten.
2

CDMS→System-DB
die System-Datenbank, wenn ihre Verbindung zum ersten Mal gebraucht wird
3

CDMS→Mandanten-DB
jede Mandanten-Datenbank einzeln, beim ersten Zugriff nach dem Start

Ergebnis: Nach einem Update mit neuen Spalten wird jede Mandanten-Datenbank also erst berührt, wenn dieser Kunde arbeitet.

Eine Mandanten-Datenbank entsteht dabei nur, wenn Anlegen ausdrücklich freigegeben ist. Ist der Datenbankserver nicht erreichbar, versucht CDMS nicht, etwas anzulegen — eine bloß unerreichbare Datenbank wäre sonst der Anlass, eine zweite daneben zu stellen. Einzelheiten unter Datenbanken, Pools, Migration.

Was in welcher Datei steht

Ein Blick auf die Namen hilft beim Suchen:

Was du siehst	Was es bedeutet
`flyway_schema_history`	die Historie von CDMS, wenn die Installation versionierte Skripte nutzt
`flyway_schema_history_cias_tenancy`	die Historie des CIAS-Moduls `cias-tenancy`
`cias_tenant`, `cias_user`, `cias_group`, `cias_audit_entry` …	Tabellen von CIAS, immer Systemtabellen
eine Datenbank mit dem Namen eines Mandantenschlüssels	die Datenbank dieses Kunden