Verarbeiten der Migration von Datenbankansichten in einer Umgebung mit mehreren Entwicklern

Question

Verarbeiten der Migration von Datenbankansichten in einer Umgebung mit mehreren Entwicklern

8

Gibt es etablierte Vorgehensweisen für die erfolgreiche Migration von Datenbanksichten in einer Umgebung mit mehreren Entwicklern / mehreren Zweigen (VCS)?

Wir haben eine Datenbankmigrationsbibliothek für alle unsere Schemaänderungen verwendet, aber es sind Probleme aufgetreten, wenn verschiedene Entwickler in verschiedenen Zweigen des Codes dieselbe Ansicht ändern, aber ihr Ausgangspunkt ist derselbe.

Jeder Entwickler hat seine eigene Kopie der Datenbank, aber da Sichten normalerweise erfordern, dass die gesamte Definition in der Migration angegeben wird, bedeutet dies, dass, wenn wir die Migrationen gegen die Staging- oder Produktionsdatenbank ausführen, welche Ansichtsmigration auch immer ausgeführt wird überschreibt zuletzt alle Änderungen, die bei vorherigen Migrationen von Ansichten vorgenommen wurden.

Beispiel:

Die Ansicht sieht momentan wie folgt aus: SELECT 'x' .
Entwickler 1 startet Zweig A und fügt eine neue Spalte hinzu. Ihre Up-Migration sieht folgendermaßen aus: SELECT 'x', 'y' .
Entwickler 2 startet Zweig B und fügt eine neue Spalte hinzu. Ihre Up-Migration sieht folgendermaßen aus: SELECT 'x', 'z' .
Entwickler 2 beendet ihren Zweig zuerst und führt die Migrationen durch. Die Ansicht sieht jetzt wie SELECT 'x', 'z' aus.
Entwickler 1 beendet nun seinen Zweig und führt die Migrationen durch. Die Ansicht sieht jetzt wie SELECT 'x', 'y' aus und die Änderungen von Entwickler 2 sind verloren gegangen.

code-first-migrations mysql database database-migration doctrine

coatesap 16.07.2015, 17:00

quelle

2 Antworten

Tags und Links code-first-migrations mysql database database-migration doctrine

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Wie bearbeite ich den Verlauf eines großen Zeichenkettenfeldes in der relationalen Datenbank?

score 2 · Answer 1

Für Ansichten oder jedes Datenbankobjekt, das jederzeit neu definiert werden kann (z. B. Funktionen), besteht die bewährte Methode darin, die aktuelle Definition der Funktion in einer eigenen Datei zu speichern, z. B. db/views/your_stuff.view.sql ; Wann immer ein Entwickler diese Ansicht ändern möchte, ändert er diese Datei und fügt dann eine Standardmigration hinzu, die die Sicht von der letzten Version einfach neu definiert (ich weiß nicht, ob Sie in Rails sind oder nicht), aber die Idee sollte hier sein sei ziemlich klar):

%Vor%

Beachten Sie, dass die tatsächliche Ansichtsdatei wie folgt aussehen sollte:

%Vor%

Dies löst Ihr Problem, denn der Workflow ist jetzt:

Die Ansicht sieht momentan wie folgt aus: SELECT 'x' FROM foos .
Entwickler 1 startet Zweig A und fügt eine neue Spalte hinzu. Sie ändern db/views/your_stuff.view.sql , um diese Änderung widerzuspiegeln. Ihre Migration führt einfach die neue Ansicht aus.
Entwickler 2 startet Zweig B und fügt eine neue Spalte hinzu. Sie ändern die gleiche Datei und fügen eine neue Migration wie oben hinzu.
Entwickler 2 beendet ihren Zweig zuerst und führt die Migrationen durch. Die Ansicht sieht jetzt wie SELECT 'x', 'z' aus.
Entwickler 1 beendet nun seine Filiale. Um jedoch in den Master zu migrieren, muss der Konflikt in der View-Datei aufgelöst werden. Sobald er dies tut und die Migrationen ausführt, enthält die Ansicht nun alle drei Spalten.

score 0 · Answer 2

Wenn sie in verschiedenen Code-Zweigen arbeiten, sollten sie unterschiedliche Datenbanken verwenden; und wenn die Zweige zusammengeführt werden, sollten die Unterschiede aufgelöst werden.

Das heißt, ich bin der Meinung, dass ein Schema als eigenes "Projekt" behandelt werden sollte. Sie erwähnen mehrere Entwickler, die eine geteilte VIEW ändern, wenn dies nicht weniger wichtig ist als eine Änderung der Signatur einer häufig verwendeten Funktion in einer gemeinsamen DLL.

Meine Antwort ist (wenn es nicht zu spät in der Entwicklung ist), dass Standard-Client-Code unter einem MySQL-Benutzer verbunden wird, der nicht berechtigt ist, die Datenbank mehr als nötig zu ändern; und haben eine "Migration" -Anwendung / Skript / was auch immer, die mit einer Verbindung unter einem Benutzerkonto mit den erforderlichen Berechtigungen ausgeführt wird, um Tabellen, Ansichten, Prozeduren usw. zu ändern.