Meine Rails-Migrationen lassen sich nicht ausführen, und ich kann meine Rails-App nicht bereitstellen. Wie kann ich von vorne beginnen?

Question

Irgendwann während meiner Rails-Entwicklung habe ich begonnen, Datenbankänderungen vorzunehmen (z.B. Löschen oder Ändern von Spalten/Tabellen), ohne Rails-Migrationen zu verwenden. Jetzt erhalte ich Fehler, wenn ich versuche, meine Rails-App von Grund auf bereitzustellen.

blaine@blaine-laptop ~/tmp/rbjacolyte $ rake db:migrate
(in /home/blaine/tmp/rbjacolyte)
==  AddHashToTrack: migrating =================================================
-- add_column(:tracks, :hash, :string)
rake aborted!
Ein Fehler ist aufgetreten, alle späteren Migrationen wurden abgebrochen:

Mysql::Error: Tabelle 'jacolyte_dev_tmp.tracks' existiert nicht: ALTER TABLE `tracks` ADD `hash` varchar(255)

(Vollständigen Trace anzeigen, indem Sie die Aufgabe mit --trace ausführen)

Wie kann ich nachdem ich es mit Raw SQL durcheinander gebracht habe, meine Produktions- und Entwicklungsumgebungen mit Migrationen synchronisieren? Ich möchte meine Rails-Anwendung ohne Datenbankfehler bereitstellen und nicht von vorne anfangen.

---

Die Daten in den Produktions- und Entwicklungsumgebungen stimmen überein, aber die Migrationen schlagen fehl. Ich möchte eine Möglichkeit, um "von vorne anzufangen".

Könnte ich einfach alle meine Migrationen löschen und dann nur noch Migrationen ab jetzt verwenden?

Answer 1

Vielleicht könnten Sie einfach alle Ihre aktuellen Migrationen loswerden und rake db:schema:dump verwenden, um eine neue schema.rb-Datei zu erstellen, und Ihre Produktionsdatenbank manuell bearbeiten, um die bisher vorgenommenen Änderungen widerzuspiegeln?

Answer 2

Der Shortcut-Weg: Fügen Sie manuell einen Eintrag zu schema_migrations für einen Zeitstempel hinzu, der einen Basiswert darstellt. Sie können danach Migrationen hinzufügen, solange sie keine falschen Annahmen über das Datenbankschema treffen, sollten sie problemlos ausgeführt werden können. Sie können nicht rückwärts migratieren, aber das ist kein großes Problem.

Das größere Problem ist, dass Sie keine DB von Grund auf neu erstellen können, was langfristig lästig werden kann.

Die Lösung dafür besteht darin, alle vorhandenen Migrationen zu löschen und eine neue zu erstellen, die das vorhandene Schema erstellt. Löschen Sie manuell alles aus der schema_migrations-Tabelle und setzen Sie einen Eintrag für diese eine neue Migration ein. Danach können Sie neue Migrationen erstellen, die auf diesem neuen Basiswert aufbauen, und sie sollten problemlos angewendet werden können. Sie sollten neue Datenbanken auf normale Weise einrichten können.

Solange Ihr direktes SQL in Rails-Migrationen enthalten ist, besteht kein Problem bei der Verwendung. Stellen Sie einfach sicher, dass Sie sowohl die Methoden #up als auch #down implementieren und es sollte gut funktionieren. Tatsächlich haben wir uns angewöhnt, RAW SQL als bewährte Methode zu verwenden, um Probleme zu vermeiden, wenn Modelle später geändert werden. Etwas wie

Foo.create(:name => 'bar')

scheint harmlos, bis das User-Modell geändert wird, um

validates_presence_of :baz

hinzuzufügen. Zu diesem Zeitpunkt wird die neue Migration gegen eine bestehende Datenbank ausgeführt, aber die frühere Migration, die die Tabelle erstellt und den Dummy-Eintrag hinzufügt, wird fehlschlagen, weil User die Validierung nicht besteht. Die Verwendung von

execute("insert into foos (name) values ('bar')")

wird gut funktionieren, solange die späteren Migrationen die neuen Spalten ordnungsgemäß befüllen, die sie hinzufügen.

Answer 3

Wenn die vorhandenen Produktionsdaten mit dem Entwicklungsdatabasenschema kompatibel sind, würde ich:

1. Die Produktionsdaten in eine Datei mit einem Programm wie mysqldump exportieren
2. Die Produktionsdatenbank löschen
3. Die Produktionsdatenbank neu erstellen
4. Die Migrationen gegen die Produktionsdatenbank ausführen und VERSION=0 angeben
5. Die Produktionsdaten aus der Datei importieren, die im ersten Schritt erstellt wurde

Wenn die Schemata nicht kompatibel sind, könnten Sie diesen Prozess möglicherweise trotzdem befolgen, müssen jedoch den SQL-Code in der im ersten Schritt erstellten Datei bearbeiten, um die Unterschiede im Schema zu berücksichtigen.

Answer 4

Ich mag Veetis Vorschlag, mit einer Änderung: rake db:schema:dump, dann verschieben Sie diese Datei auf Ihre Entwicklungsmaschine. Vereinfachen Sie Ihre bisherigen Rails-Migrationen (siehe diesen SO-Thread dazu), entfernen Sie die meisten Ihrer Migrationen und überarbeiten Sie Ihre Migrationen, um mit Ihrem neuen Schema zu arbeiten.

Bringen Sie dies auf Ihrer Entwicklermaschine zum Laufen, committen und deployen Sie.