X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=sidebyside;f=doc%2Fhtml%2Fch04s03.html;h=20ec5cabe3d38e9bc0c0719b1a9b189a24e8320b;hb=8974129421f2b7c98495f8036e5f4d2d0ac7b738;hp=cae5a7b74b16457f90f874d41830be7f08089215;hpb=b948bb619c8086b8f05aac962d44d075aea17822;p=kivitendo-erp.git diff --git a/doc/html/ch04s03.html b/doc/html/ch04s03.html index cae5a7b74..20ec5cabe 100644 --- a/doc/html/ch04s03.html +++ b/doc/html/ch04s03.html @@ -1,9 +1,9 @@
-Der alte Mechanismus für SQL-Upgradescripte, der auf einer +
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 Lx-Office 2.4.1 deutlich erweitert. + 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, @@ -13,7 +13,7 @@ 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.
Lx-Office merkt sich dabei, welches der Upgradescripte in + 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 @@ -44,7 +44,7 @@ erfolgen.
depends
Optional. Eine mit Leerzeichen getrennte Liste von "tags", - von denen dieses Upgradescript abhängt. Lx-Office stellt sicher, + von denen dieses Upgradescript abhängt. kivitendo stellt sicher, dass die in dieser Liste aufgeführten Scripte bereits durchgeführt wurden, bevor dieses Script ausgeführt wird.
Abhängigkeiten werden rekursiv betrachtet. Wenn also ein Script "b" existiert, das von Ãnderungen in "a" abhängt, und @@ -58,7 +58,7 @@ der Scripte ausgeführt werden, die die gleichen Abhängigkeitstiefen besitzen. Fehlt dieser Parameter, so wird der Wert 1000 benutzt.
Dies ist reine Kosmetik. Für echte Reihenfolgen muss - "depends" benutzt werden. Lx-Office sortiert die auszuführenden + "depends" benutzt werden. kivitendo sortiert die auszuführenden Scripte zuerst nach der Abhängigkeitstiefe (wenn "z" von "y" abhängt und "y" von "x", so hat "z" eine Abhängigkeitstiefe von 2, "y" von 1 und "x" von 0. "x" würde hier zuerst ausgeführt, @@ -70,16 +70,16 @@ ausgeführt.
Um die Arbeit mit den Abhängigkeiten etwas zu erleichtern,
existiert ein Hilfsscript namens
"scripts/dbupgrade2_tool.pl
". Es muss aus dem
- Lx-Office-ERP-Basisverzeichnis heraus aufgerufen werden. Dieses Tool
+ kivitendo-ERP-Basisverzeichnis heraus aufgerufen werden. Dieses Tool
liest alle Datenbankupgradescripte aus dem Verzeichnis
sql/Pg-upgrade2
aus. Es benutzt dafür die
- gleichen Methoden wie Lx-Office selber, sodass alle Fehlersituationen
+ gleichen Methoden wie kivitendo selber, sodass alle Fehlersituationen
von der Kommandozeile überprüft werden können.
Wird dem Script kein weiterer Parameter übergeben, so wird nur eine Ãberprüfung der Felder und Abhängigkeiten vorgenommen. Man kann sich aber auch Informationen auf verschiedene Art ausgeben lassen:
Listenform: "./scripts/dbupgrade2_tool.pl --list"
Gibt eine Liste aller Scripte aus. Die Liste ist in der - Reihenfolge sortiert, in der Lx-Office die Scripte ausführen + Reihenfolge sortiert, in der kivitendo die Scripte ausführen würde. Es werden neben der Listenposition der Tag, die Abhängigkeitstiefe und die Priorität ausgegeben.
Baumform: "./scripts/dbupgrade2_tool.pl --tree"
Listet alle Tags in Baumform basierend auf den