X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Fhtml%2Fch04s03.html;h=93dab9124d418de49c71530ecf0d151df4f5c631;hb=c3fa430edf27cefc8d45597e8784d0e847a72ff4;hp=b8e68f9937321e154f5a783b0953d24ac14f4d5c;hpb=7ff9c8f696520daa18c603a001263f45824b7c69;p=kivitendo-erp.git diff --git a/doc/html/ch04s03.html b/doc/html/ch04s03.html index b8e68f993..93dab9124 100644 --- a/doc/html/ch04s03.html +++ b/doc/html/ch04s03.html @@ -1,22 +1,12 @@
-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:
charset
- 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.
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 für SQL-Upgradedateien der Zeichensatz
+ "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
@@ -67,7 +56,33 @@
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; +