Entwicklung/Datenbankversionierung: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Entwicklung/Datenbankversionierung (Quelltext anzeigen)
Version vom 24. Juni 2013, 11:53 Uhr
, 24. Juni 2013Triggerhandling neu
(Triggerhandling neu) |
|||
| Zeile 20: | Zeile 20: | ||
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 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 Funktionsdefintionen in maintain.php, die der Übersicht halber weiter benötigt werden. | |||
Solange es kein besseres Konzept gibt, wird daher wie folgt vorgegangen: | |||
Dies | * 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 sie neue Datenbankfelder benötigen kann (Henne-Ei-Problem). | ||
* Bei Definition der Mutationen darauf achten, ob diese 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 kompletten, 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). | |||
[[Kategorie:Entwicklung|Datenbankversionierung]] | [[Kategorie:Entwicklung|Datenbankversionierung]] | ||