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.
Die Kontrollinformationen sollten sich am Anfang der jeweiligen +
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.
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:
Empfohlen. Gibt den Zeichensatz an, in dem das Script
geschrieben wurde, z.B. "UTF-8". Aus
Kompatibilitätsgründen mit alten Upgrade-Scripten wird bei
- Abwesenheit des Tags der Zeichensatz
- "ISO-8859-15" angenommen.
ISO-8859-15" angenommen. Perl-Upgradescripte
+ hingegen müssen immer in UTF-8 encodiert sein und sollten
+ demnach auch ein "use utf8;"
+ enthalten.description
Benötigt. Eine Beschreibung, was in diesem Update passiert. Diese wird dem Benutzer beim eigentlichen - Datenbankupdate angezeigt. Während der Tag in englisch gehalten + Datenbankupdate angezeigt. Während der Tag in Englisch gehalten sein sollte, sollte die Beschreibung auf Deutsch erfolgen.
depends
@@ -67,7 +68,41 @@
ignore
Optional. Falls der Wert auf 1 (true) steht, wird das Skript bei der Anmeldung ignoriert und entsprechend nicht - ausgeführt.
In Perl geschriebene Datenbankscripte werden nicht einfach so + ausgeführt sondern müssen sich an gewisse Konventionen halten. Dafür + bekommen sie aber auch einige Komfortfunktionen bereitgestellt.
Ein Upgradescript stellt dabei eine vollständige Objektklasse
+ dar, die vom Elternobjekt "SL::DBUpgrade2::Base"
+ erben und eine Funktion namens "run" zur Verfügung
+ stellen muss. Das Script wird ausgeführt, indem eine Instanz dieser
+ Klasse erzeugt und darauf die erwähnte "run"
+ aufgerufen wird.
Zu beachten ist, dass sich der Paketname der Datei aus dem Wert
+ für "@tag" ableitet. Dabei werden alle Zeichen, die
+ in Paketnamen ungültig wären (gerade Bindestriche), durch Unterstriche
+ ersetzt. Insgesamt sieht der Paketname wie folgt aus:
+ "SL::DBUpgrade2::tag".
Welche Komfortfunktionen zur Verfügung stehen, erfahren Sie in + der Perl-Dokumentation zum oben genannten Modul; aufzurufen mit + "perldoc SL/DBUpgrade2/Base.pm".
Ein Mindestgerüst eines gültigen Perl-Upgradescriptes sieht wie + folgt aus:
# @tag: beispiel-upgrade-file42
+# @description: Ein schönes Beispielscript
+# @depends: release_3_1_0
+package SL::DBUpgrade2::beispiel_upgrade_file42;
+
+use strict;
+use utf8;
+
+use parent qw(SL::DBUpgrade2::Base);
+
+sub run {
+ my ($self) = @_;
+
+ # hier Aktionen ausführen
+
+ return 1;
+}
+
+1;
+