X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=sidebyside;f=doc%2Fhtml%2Fch04s03.html;h=bef5e5ded26bc62eddefe1540259efe01d37f3b9;hb=9d17c830e06c8b9a24af18b70c622a4fbc8d1b7a;hp=39f03d32c1cf0a4c32bf0c821f7977d73a85113d;hpb=f1a40f51c548b045c6d4ae38766bf7094a8f193a;p=kivitendo-erp.git diff --git a/doc/html/ch04s03.html b/doc/html/ch04s03.html index 39f03d32c..bef5e5ded 100644 --- a/doc/html/ch04s03.html +++ b/doc/html/ch04s03.html @@ -1,22 +1,12 @@ - 4.3. SQL-Upgradedateien

4.3. SQL-Upgradedateien

4.3.1. Einführung

Der alte Mechanismus für SQL-Upgradescripte, der auf einer - Versionsnummer beruht und dann in sql/Pg-upgrade nach einem Script für - diese Versionsnummer sucht, schränkt sehr ein, z.B. was die parallele - Entwicklung im stable- und unstable-Baum betrifft.

Dieser Mechanismus wurde für kivitendo 2.4.1 deutlich erweitert. - Es werden weiterhin alle Scripte aus sql/Pg-upgrade ausgeführt. - Zusätzlich gibt es aber ein zweites Verzeichnis, sql/Pg-upgrade2. In - diesem Verzeichnis muss pro Datenbankupgrade eine Datei existieren, - die neben den eigentlich auszuführenden SQL- oder Perl-Befehlen einige - Kontrollinformationen enthält.

Neu sind die Kontrollinformationen, die Abhängigkeiten und - Prioritäten definieren können werden, sodass Datenbankscripte zwar in - einer sicheren Reihenfolge ausgeführt werden (z.B. darf ein "ALTER - TABLE" erst ausgeführt werden, wenn die Tabelle mit "CREATE TABLE" - angelegt wurde), diese Reihenfolge aber so flexibel ist, dass man - keine Versionsnummern mehr braucht.

kivitendo merkt sich dabei, welches der Upgradescripte in - sql/Pg-upgrade2 bereits durchgeführt wurde und führt diese nicht - erneut aus. Dazu dient die Tabelle "schema_info", die bei der - Anmeldung automatisch angelegt wird.

4.3.2. Format der Kontrollinformationen

Die Kontrollinformationen sollten sich am Anfang der jeweiligen + 4.3. SQL-Upgradedateien

4.3. SQL-Upgradedateien

4.3.1. Einführung

Datenbankupgrades werden über einzelne Upgrade-Scripte gesteuert, die sich im Verzeichnis sql/Pg-upgrade2 + befinden. In diesem Verzeichnis muss pro Datenbankupgrade eine Datei existieren, die neben den eigentlich auszuführenden SQL- oder + Perl-Befehlen einige Kontrollinformationen enthält.

Kontrollinformationen definieren Abhängigkeiten und Prioritäten, sodass Datenbankscripte zwar in einer sicheren Reihenfolge + ausgeführt werden (z.B. darf ein ALTER TABLE erst ausgeführt werden, wenn die Tabelle mit CREATE + TABLE angelegt wurde), diese Reihenfolge aber so flexibel ist, dass man keine Versionsnummern braucht.

kivitendo merkt sich dabei, welches der Upgradescripte in sql/Pg-upgrade2 bereits durchgeführt wurde und + führt diese nicht erneut aus. Dazu dient die Tabelle "schema_info", die bei der Anmeldung automatisch angelegt + wird.

4.3.2. Format der Kontrollinformationen

Die Kontrollinformationen sollten sich am Anfang der jeweiligen Upgradedatei befinden. Jede Zeile, die Kontrollinformationen enthält, hat dabei das folgende Format:

Für SQL-Upgradedateien:

-- @key: value

Für Perl-Upgradedateien:

# @key: value

Leerzeichen vor "value" werden entfernt.

Die folgenden Schlüsselworte werden verarbeitet: