Entwicklung/Datenbankversionierung: Unterschied zwischen den Versionen

← Zum vorherigen Versionsunterschied

Entwicklung/Datenbankversionierung (Quelltext anzeigen)

Version vom 24. Oktober 2013, 10:00 Uhr

2.576 Bytes hinzugefügt , 24. Oktober 2013

K

→‎Trigger & Stored Procedures

Dl6hbo

82

Bearbeitungen

@@ Zeile 16: / Zeile 16: @@
 In der Tabelle 'sysconfig' einer OC-Installation gibt es (ab [https://github.com/OpencachingDeutschland/oc-server3/blob/master/htdocs/doc/sql/db-changes.txt#L64 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. Evtl. müssen Indizes geändert oder neu definiert werden, um die nötige Performance sicherzustellen.
+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. {{Codepath2|htdocs/doc/sql|modification-dates.txt}} und {{Codepath2|htdocs|restorecaches.php}}). 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.
-'''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).
+Wenn mehrere Entwickler gleichzeitig neue Mutationen definieren, ist es Aufgabe des Code-Maintainers, diese in passender Reihenfolge zusammenzuführen.
+== Felder oder Tabellen löschen oder umbenennen ==
+Nicht mehr vorhandene Felder oder Tabellen sind inkompatibel zu älteren Versionsständen. Man kann dann auf einem Entwicklersystem nicht mehr testweise auf eine alte Codeversion zurückgehen, was sehr hilfreich ist um herauszufinden, wann ein Bug entstanden ist. Auch das Umschalten zwischen verschiedenen aktiven Branches kann schon zum Problem werden.
+(Es gibt natürlich nie eine Garantie dass ein Downgrade 100%ig funktioniert, weil sich auch Datenbankinhalte in inkompatibler Weise geändert haben können. Im Großen und Ganzen funktioniert es aber.)
+Umbenennung oder Löschungen sind daher nicht zu empfehlen. Nicht mehr verwendete Felder und Tabellen werden stattdessen mit dem Kommentar "obsolete" versehen.
+== 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 der 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).
-Wenn mehrere Entwickler gleichzeitig neue Mutationen definieren, ist es Aufgabe des Code-Maintainers, diese in passender Reihenfolge zusammenzuführen.
+== OKAPI ==
+Der OKAPI-Code greift parallel zum OC.de-Code auf die Datenbank zu. Bei Änderungen an Datenbankstruktur oder -inhalten ist daher immer zu prüfen, ob die OKAPI betroffen ist und angepasst werden muss.
+Unter Umständen müssen Trigger aktualisiert werden, damit die OKAPI Änderungen an Cache- oder Logabhängigen Daten mitbekommt; siehe dazu [https://github.com/OpencachingDeutschland/oc-server3/blob/master/htdocs/doc/sql/modification-dates.txt modification-dates.txt].
+Änderungen an OKAPI-eigenen Tabellen (okapi_*) werden von der OKAPI selbst verwaltet und spielen hier keine Rolle. Sie werden via <code>okapi/views/update.php</code> eingepflegt.
 [[Kategorie:Entwicklung|Datenbankversionierung]]