Entwicklung/Datenbankversionierung

Änderungen am Datenbankinhalt werden von den Entwicklern an vier Stellen eingepflegt:

• statische Daten in htdocs/doc/sql/static-data/data.sql
• stored procs & trigger in htdocs/doc/sql/stored-proc/maintain.php
• Änderungen an Tabellenstrukturen und Indizes in bin/dbsv-update.php
• Änderungen an der OKAPI-Datenbank in htdocs/okapi/views/update.php.

Das Script bin/dbupdate.php spielt alle diese Dinge in eine OC-Installation – z.B. ein Entwicklersystem – ein, bringt die Datenbank also auf den aktuellen Stand.

Der OKAPI-Code funktioniert nicht besonders gut, wenn man ihn von der Kommandozeile aus verwendet. Falls das OKAPI-Datenbankupdate einen Fehler produzieren sollte, muss man es anschließend von Hand via http://.../okapi/update aufrufen.

Versionierung der Datenbankstruktur

dbsv-update.php beinhaltet eine Versionierung der Datenbankstruktur.

In der Tabelle 'sysconfig' einer OC-Installation gibt es (ab Datenbankstand April 2013 bzw. Codestand a654761 vom 22. April) den Eintrag 'db_version' mit dem aktuellen Versionsstand der Datenbank, fortlaufend durchnumeriert ab 100. Für jede neue Version gibt es eine "Mutationsfunktion" in dbsv-update.php, die die Datenbank auf den neuen Versionsstand bringt.

Wenn du eine Änderung an einer Datenbanktabelle vornehmen (oder eine neue einfügen) möchtest, vergewissere dich zuerst sorgfältig, welche Folgen dies hat. Neue Informationen zu Caches und Logs müssen an vielen Stellen berücksichtigt werden, inklusive XML-Schnittstelle, OKAPI, evtl. auch Ocprop etc. Evtl. müssen Änderungen auch in vorhandene Trigger eingebaut werden oder benötigen neue Trigger, um Kosistenz zu gewährleisten (vgl. modification-dates.txt). Evtl. müssen Indizes geändert oder neu definiert werden, um die nötige Performance sicherzustellen.

Wenn du sicher bist, die Datenbank ändern zu wollen, ändere sie NICHT direkt, sondern schreibe eine neue Mutationsfunktion in dbsv-update.php, die die Änderung vornimmt. Vorhandene Funktionen können als Vorlage dienen. Teste deine Funktion anschließend mit "php dbsv-update.php" auf der Kommandozeile. Wenn es nicht wie beabsichtigt funktionierte, mache die Änderung rückgängig und setze sysconfig.db_version eins zurück, bevor du es wieder versuchst.

Wenn mehrere Entwickler gleichzeitig neue Mutationen definieren, ist es Aufgabe des Code-Maintainers, diese in passender Reihenfolge zusammenzuführen.

Trigger & Stored Procedures

Um das Versionierungskonzept vollständig durchzuhalten, müssten eigentlich auch alle Änderungen an Triggern und Stored Procedures über die Mutationen erfolgen. Es bestünde dann allerdings die Gefahr von Inkonsistenzen zwischen den Mutationen den kompletten Funktionsdefinitionen in maintain.php, die der Übersicht halber weiter benötigt werden.

Solange es kein besseres Konzept gibt, wird daher wie folgt vorgegangen:

• Wenn eine Mutation geänderte/neue Trigger benötigt, die mit dem gleichen Codeupdate eingeführt werden, muss sie diese entweder zunächst definieren oder deren Funktionalität nachbilden (siehe z.B. Version 102: hier wird der neue sp_updateall_hiddenstat()-Code ausgeführt). Dies ist nötig, weil maintain.php erst nach den Mutationen durchläuft, da es neue Datenbankfelder benötigen kann (Henne-Ei-Problem).

• Bei Definition der Mutationen darauf achten, ob sie irgendwelchen SQL-Code enthalten der auf Trigger angewiesen ist. Wenn ja, entsprechende Maßnahmen ergreifen z.B.
  • Diese Trigger in der Mutation neu anlegen, oder
  • die Funktionalität der Trigger nachbilden, oder
  • eine Zwischenmutation mit einem versionierten Triggerupdate einfügen (siehe Mutation #113).

Als präventive Maßnahme kann in größeren Abständen pauschal ein komplettes Triggerupdate eingefügt werden (siehe Mutation #113).