- <title>4.3. SQL-Upgradedateien</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="Lx-Office: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s02.html" title="4.2. Entwicklung unter FastCGI"><link rel="next" href="ch04s04.html" title="4.4. Translations and languages"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.3. SQL-Upgradedateien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s02.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s04.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.3. SQL-Upgradedateien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="db-upgrade-files"></a>4.3. SQL-Upgradedateien</h2></div></div></div><div class="sect2" title="4.3.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.introduction"></a>4.3.1. Einführung</h3></div></div></div><p>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.</p><p>Dieser Mechanismus wurde für Lx-Office 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.</p><p>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.</p><p>Lx-Office 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.</p></div><div class="sect2" title="4.3.2. Format der Kontrollinformationen"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.format"></a>4.3.2. Format der Kontrollinformationen</h3></div></div></div><p>Die Kontrollinformationen sollten sich am Anfang der jeweiligen
+ <title>4.3. SQL-Upgradedateien</title><link rel="stylesheet" type="text/css" href="style.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1-RC2"><link rel="home" href="index.html" title="kivitendo 3.1.0: Installation, Konfiguration, Entwicklung"><link rel="up" href="ch04.html" title="Kapitel 4. Entwicklerdokumentation"><link rel="prev" href="ch04s02.html" title="4.2. Entwicklung unter FastCGI"><link rel="next" href="ch04s04.html" title="4.4. Translations and languages"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.3. SQL-Upgradedateien</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s02.html">Zurück</a> </td><th width="60%" align="center">Kapitel 4. Entwicklerdokumentation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s04.html">Weiter</a></td></tr></table><hr></div><div class="sect1" title="4.3. SQL-Upgradedateien"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="db-upgrade-files"></a>4.3. SQL-Upgradedateien</h2></div></div></div><div class="sect2" title="4.3.1. Einführung"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.introduction"></a>4.3.1. Einführung</h3></div></div></div><p>Datenbankupgrades werden über einzelne Upgrade-Scripte gesteuert, die sich im Verzeichnis <code class="filename">sql/Pg-upgrade2</code>
+ befinden. In diesem Verzeichnis muss pro Datenbankupgrade eine Datei existieren, die neben den eigentlich auszuführenden SQL- oder
+ Perl-Befehlen einige Kontrollinformationen enthält.</p><p>Kontrollinformationen definieren Abhängigkeiten und Prioritäten, sodass Datenbankscripte zwar in einer sicheren Reihenfolge
+ ausgeführt werden (z.B. darf ein <code class="literal">ALTER TABLE</code> erst ausgeführt werden, wenn die Tabelle mit <code class="literal">CREATE
+ TABLE</code> angelegt wurde), diese Reihenfolge aber so flexibel ist, dass man keine Versionsnummern braucht.</p><p>kivitendo merkt sich dabei, welches der Upgradescripte in <code class="filename">sql/Pg-upgrade2</code> bereits durchgeführt wurde und
+ führt diese nicht erneut aus. Dazu dient die Tabelle "<code class="literal">schema_info</code>", die bei der Anmeldung automatisch angelegt
+ wird.</p></div><div class="sect2" title="4.3.2. Format der Kontrollinformationen"><div class="titlepage"><div><div><h3 class="title"><a name="db-upgrade-files.format"></a>4.3.2. Format der Kontrollinformationen</h3></div></div></div><p>Die Kontrollinformationen sollten sich am Anfang der jeweiligen