Datenbankmigration

Aus THM-Wiki
Wechseln zu: Navigation, Suche

Eine Datenbank gehört unter Versionskontrolle genau wie der Quellcode. Denn sobald mehrere Entwickler am gleichen Projekt arbeiten, tritt folgendes Problem auf: Ein Entwickler verändert das Datenbankschema und checkt neuen Code ein. Wollen die übrigen Entwickler diesen Code verwenden, brauchen auch sie das veränderte Datenbankschema. Also müssen sie ihre Datenbank migrieren. Werden parallel viele Änderungen an der Datenbank durchgeführt, geht irgendwann die Übersicht verloren, auf welchem Stand denn nun die eigene Datenbank ist. Wird die Datenbank dagegen versioniert, ist immer klar, auf welchem Stand sie ist und ob evtl. noch Schema-Änderungen fehlen, die noch nicht eingepflegt sind.

Eine Versionierung ist wichtig, um den Stand einer Datenbank zu verändern, die sich in Betrieb befindet. Das Betrifft sowohl die lokale Entwicklerdatenbank, als auch eine Produktionsdatenbank. Für die Versionierung gibt es zwei Möglichkeiten: Zum Einen durch Migrationsdateien, welche die Schema-Änderungen beschreiben, und zum Anderen durch das Vorhalten des gesamten Schemas in Form einer Konfigurationsdatei.

Datenbankversionierung in eStudy

In eStudy wird die Datenbankversionierung über simple Migrationsdateien geregelt: Im Wurzelverzeichnis von eStudy befindet sich der Ordner SQL, darin befinden sich wiederum Dateien mit der Bezeichnung migration_<revisionsnummer>.sql und rollback_<revisionsnummer>.sql. Die Revisionsnummer wird mit jedem Dateipärchen um 1 erhöht.

Jede Migrationsdatei beinhaltet die Datenbankänderungen, die für die angegegebene Revisionsnummer wichtig sind. Jede Rollbackdatei beinhaltet dagegen den SQL-Code, um diese Datenbankänderungen wieder rückgängig machen zu können.

Ein Beispiel: Für ein Feature wird eine neue Tabelle benötigt. Gerade ist Revision 6500 aktuell. Es wird daher zunächst die Migrationsdatei migration_6501.sql (+1 zur aktuellen Revision) mit folgendem Inhalt angelegt:

CREATE TABLE myFeatureTable (
  -- Tabellenspalten etc...
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Dazu wird des Weiteren die Rollbackdatei rollback_6501.sql erstellt:

DROP TABLE myFeatureTable;

In der Rollbackdatei wird also die in der Migrationsdatei erstellte Tabelle wieder gelöscht. Genau so verhält es sich mit neuen Tabellenspalten und sonstigen Datenbankänderungen: In der Migrationsdatei werden diese hinzugefügt und in der Rollbackdatei wieder entfernt.

Versionsverwaltung

Intern speichert eStudy die gerade aktuelle Datenbankversion in der settings-Tabelle unter dem Bezeichner dbversion. Auf eine neue Version kann über die Administrationsseite innerhalb von eStudy gewechselt werden.

Wichtige Hinweise

Achtung: Neben den Migrationsdateien, welche für den laufenden Betrieb gedacht sind, müssen immer auch die modulspezifischen SQL-Dateien auf dem aktuellsten Stand gehalten werden. Denn diese werden im Falle einer Neuinstallation ausgeführt, die Migrationsdateien jedoch nicht.

Das System ist des Weiteren noch nicht sehr schlau: Typischerweise verändert man während der Entwicklung zuerst die Datenbank und erstellt erst im Anschluss die Migrationsdateien. Das heißt, die Änderungen sind bereits eingespielt. Nun kann die Migrationsdatei natürlich nicht mehr über eStudy eingespielt werden, trotzdem wird sie als neue Datenbankversion angezeigt. Sie blockiert damit den gesamten Migrationsprozess. Um dies zu verhindern, muss man die Datenbankversion selber auf den aktuellen Wert setzen.

Wenn Migrationsskripte beispielsweise eine Stored Procedure beinhalten, können sie nicht vom System verarbeitet werden, da deren Syntax nicht verarbeitet werden kann. Wann immer dies der Fall ist, darf die SQL-Datei nicht im Migrationsformat (dh. mit der oben beschriebenen Benennung) gespeichert werden. Sie muss statt dessen manuell eingepflegt werden.

Kollision der Revisionsnummer

Durch die verteilte Entwicklung in verschiedene Repositories und Branches kann es sehr leicht dazu kommen, dass eine Revisionsnummer von mehreren Entwicklern verwendet wird. Dies führt im besten Fall zu einem Merge-Konflikt. Auf keinen Fall dürfen die Änderungen gemerged werden -- auch nicht automatisch vom VCS! Wenn ein anderer Entwickler bereits die eigene Revisionsnummer verwendet, muss die Nummer erhöht werden. Das heißt, es müssen neue SQL-Dateien geschrieben werden. Eigene Änderungen dürfen nie zu bereits bestehenden Migrationsdateien hinzugefügt werden.