Entwicklung/Datenbankversionierung: Unterschied zwischen den Versionen

Entwicklung/Datenbankversionierung (Quelltext anzeigen)

Version vom 24. Juni 2013, 11:53 Uhr

776 Bytes hinzugefügt , 24. Juni 2013

Triggerhandling neu

Following

Administratoren

2.505

Bearbeitungen

@@ 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 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.
-'''Achtung:''' dbsv-update läuft ''vor'' dem Storedproc/Trigger-Update (maintain.php), also noch mit den Triggern des letzten Versionsstandes. Falls geänderte Trigger benötigt werden, müssen dieser hier zusätzlich deklariert oder deren Code eingefügt werden (siehe z.B. Version 102: hier wird der neue sp_updateall_hiddenstat()-Code ausgeführt).
+Solange es kein besseres Konzept gibt, wird daher wie folgt vorgegangen:
-Dies gilt prinzipiell auch rückwirkend für Triggeränderungen aus früheren Mutationen, weil mehrere davon in einem Aufruf durchlaufen können. Um dieses Problem zu umgehen, können Zwischenmutationen eingefügt werden, die maintain.php aufrufen; siehe Version 113.
+* 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).
-Wenn mehrere Entwickler gleichzeitig neue Mutationen definieren, ist es Aufgabe des Code-Maintainers, diese in passender Reihenfolge zusammenzuführen.
+Als präventive Maßnahme kann in größeren Abständen pauschal ein komplettes Triggerupdate eingefügt werden (siehe Mutation #113).
 [[Kategorie:Entwicklung|Datenbankversionierung]]