Verwaltung der Datenbankstruktur über mehrere Zweigstellen hinweg

Die Datenbankschicht einer Anwendung ist ein eigenständiges Wesen und wird nur durch Migrationen gesteuert. Denken Sie bei der Erstellung neuer Migrationen daran, die geplante Umwandlung einer Datenbankstruktur umkehrbar zu machen. Natürlich können wir in extremen Fällen die IrreversibleMigration im unten Methode. Dies informiert uns auch über die Tatsache, dass die Migration nicht rückgängig gemacht werden kann. Es gibt verschiedene Arten von Änderungen, die wir bei der Migration vornehmen - Erstellen, Ändern und Entfernen von Tabellen, Spalten oder Indizes. Die Lösch- und Änderungsvorgänge sind am empfindlichsten gegenüber Änderungen. Und warum? Betrachten wir das folgende Szenario: Wir arbeiten mit dem Master-Zweig, der unser Hauptarbeitspfad ist. Derzeit haben wir eine Tabelle:

 class CreateArticles < ActiveRecord::Migration
   def change
     create_table :articles do |t|
       t.string :name
       t.text :description
       t.string :status, null: false
       t.timestamps null: false
     end
   end
 end

Unser Artikel Modell hat solche Validierungen, die das Vorhandensein von Name, Beschreibung und Status Attribute.

 Klasse Artikel < ActiveRecord::Base
   validiert :name, Vorhandensein: true
   validiert :description, Vorhandensein: true
   validiert :status, Vorhandensein: true
 end

Wir führen Änderungen in unserem Artikel Tabelle auf Funktion Entwicklungszweig und wir löschen die Status Spalte.

 class RemoveStatusColumnFromArticles < ActiveRecord::Migration
   def change
     remove_spalte :artikel, :status, :string
   end
 end

Wir führen die Migration durch:

 $ [Beispiel/Feature]: bundle exec rake db:migrate
 == 20150605120955 RemoveStatusColumnFromArticles: migrieren ===================
 -- remove_column(:articles, :status, :string)
   -> 0.0717s
 == 20150605120955 RemoveStatusColumnFromArticles: migriert (0.0718s) ==========

Das Schema für eine Datenbank ändert sich:

diff --git a/db/schema.rb b/db/schema.rb
index 2a100a9..76438c1 100644 --- a/db/schema.rb +++ b/db/schema.rb @@ -11,14 +11,13 @@ #

Es wird dringend empfohlen, dass Sie diese Datei in Ihr Versionskontrollsystem einchecken.

-ActiveRecord::Schema.define(version: 20150605120350) do
+ActiveRecord::Schema.define(version: 20150605120955) do
  createtable "Artikel", force: :cascade do |t|
    t.string "name"
    t.text "Beschreibung"
- t.string "status", null: false t.datetime "createdat", null: false
    t.datetime "aktualisiert_am", null: false
  Ende

end

Als nächstes übertragen wir die Änderungen in die Funktion Zweig. Um dieses Problem zu simulieren, schalten wir den aktuellen Zweig auf Master um. Die Basisstruktur wurde durch die Migration geändert, wodurch die Status Spalte auf der Funktion Zweig. Versuchen wir, den folgenden Befehl zu verwenden:

Artikel.create!(Name: "Kaboom", Beschreibung: "Lorem ipsum...", Status: "aktiv")

Was geschieht nach der Ausführung der oben genannten Code? Der Fehler: ActiveRecord::UnknownAttributeError: unbekanntes Attribut 'status' für Artikel ausgelöst werden, und zwar wegen der inkompatiblen Strukturversion einer Datenbank. Bevor wir den Zweig auf Master umstellen, sollten wir die Migration zurücknehmen, die die Status Spalte aus der Artikel Tisch.

Was können wir tun, um zu prüfen, ob wir einige Migrationen rückgängig machen müssen, bevor wir die Zweige wechseln? Mit Hilfe des Versionskontrollsystems (hier ist es git) können wir unsere Arbeit überprüfen, indem wir einen hilfreichen Alias erstellen:

 ~/.gitconfig
 [alias]
  migrations = "!f() { git diff --name-only $1..$2 db/migrate | tr -d '[A-Za-z/_.]'; }; f"

Ausführen der Git-Migrationen Master-Funktion wird die Liste der Migrationsversionen angezeigt, die sich auf Funktion Zweigstellen, und die nicht auf Meister.

 $ [example/feature]: git migrations master feature
 20150605120955

Dank dieser Informationen können wir die Änderungen an der Datenbankstruktur, die vor dem Wechsel zum Master vorgenommen wurden, problemlos rückgängig machen.

 $ [Beispiel/Feature]: bundle exec rake db:migrate:down VERSION=20150605120955
 == 20150605120955 RemoveStatusColumnFromArticles: Rückgängig ===================
 -- add_column(:articles, :status, :string)
   -> 0.0009s
 == 20150605120955 RemoveStatusColumnFromArticles: Rückgängig gemacht (0.0045s) ==========

Eine weitere Maßnahme, die wir nach dem Rollback der Migration durchführen sollten, ist die Wiederherstellung des Status eines Datenbankschemas.

$ [Beispiel/Feature]: git status
Auf dem Zweig Feature
Änderungen nicht für die Übergabe bereitgestellt:
 (verwenden Sie "git add ...", um zu aktualisieren, was übertragen werden soll)
 (verwenden Sie "git checkout -- ...", um Änderungen im Arbeitsverzeichnis zu verwerfen)

geändert: db/schema.rb

keine Änderungen zum Commit hinzugefügt (verwenden Sie "git add" und/oder "git commit -a")
$ [Beispiel/Feature]: git checkout db/schema.rb
$ [Beispiel/Merkmal]: git status
Auf Zweigfunktion
nichts zu übertragen, Arbeitsverzeichnis sauber

Jetzt können wir einfach zur Meister Zweigstelle.

Das gegebene Beispiel ist kein kompliziertes Problem, aber es sollte Ihnen helfen zu erkennen, wie wichtig es ist, die Struktur einer Datenbank während der Änderung des Arbeitskontextes zu erhalten.