X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=sidebyside;f=doc%2Fhtml%2Fch04s03.html;h=3532f0640be822b356a67506ee6c8c1f8212ab15;hb=667cfdce6bf2a06094339fc09fb7d27fc1636d96;hp=ae129453bc28c6694454b126cd17a11d98b0889c;hpb=d63ea7c6b814244c99eb40d56633a96debf93a3f;p=kivitendo-erp.git diff --git a/doc/html/ch04s03.html b/doc/html/ch04s03.html index ae129453b..3532f0640 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 - 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
@@ -56,16 +68,24 @@
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_0_0 +# @depends: release_3_1_0 package SL::DBUpgrade2::beispiel_upgrade_file42; use strict;