X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/c6dd542b51ae9549ad42a54f9023b905412bbab9..0e14ae06e360e5560c691ddfc66068de3c0ed8f8:/doc/html/ch04s03.html diff --git a/doc/html/ch04s03.html b/doc/html/ch04s03.html index 7efff6e9f..271b12e25 100644 --- a/doc/html/ch04s03.html +++ b/doc/html/ch04s03.html @@ -1,12 +1,20 @@
-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 +
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 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.
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
@@ -56,14 +68,22 @@
                      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 + 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;