Entwicklung/Datenbankversionierung: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Entwicklung/Datenbankversionierung (Quelltext anzeigen)
Version vom 24. Oktober 2013, 10:00 Uhr
, 24. Oktober 2013→Trigger & Stored Procedures
Dl6hbo (Diskussion | Beiträge) |
|||
| (2 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt) | |||
| 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. | 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 (vgl. | 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. | 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. | ||
| Zeile 32: | Zeile 32: | ||
== Trigger & Stored Procedures == | == 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 | 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: | Solange es kein besseres Konzept gibt, wird daher wie folgt vorgegangen: | ||
| Zeile 44: | Zeile 44: | ||
Als präventive Maßnahme kann in größeren Abständen pauschal ein komplettes Triggerupdate eingefügt werden (siehe Mutation #113). | Als präventive Maßnahme kann in größeren Abständen pauschal ein komplettes Triggerupdate eingefügt werden (siehe Mutation #113). | ||
== 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]] | [[Kategorie:Entwicklung|Datenbankversionierung]] | ||