Rake DB: Schema: Laden vs. Migrationen

171

Sehr einfache Frage hier: Wenn Migrationen langsam und umständlich werden können, wenn eine App komplexer wird, und wenn wir rake db:schema:loadstattdessen viel sauberer anrufen können, warum gibt es überhaupt Migrationen?

Wenn die Antwort auf das oben Gesagte lautet, dass Migrationen für die Versionskontrolle verwendet werden (eine schrittweise Aufzeichnung von Änderungen an der Datenbank), rake db:schema:loadbehalten sie dann ihre primäre Funktion bei , wenn eine App komplexer wird und stattdessen häufiger verwendet wird?

Vorsicht:

Aus den Antworten auf diese Frage: rake db:schema:load Löscht Daten auf einem Produktionsserver. Seien Sie also vorsichtig, wenn Sie sie verwenden.

ruby-on-rails ruby-on-rails-3 migration

— sscirrus
quelle

5

+1 Ich habe den Zweck von Migrationen nie verstanden. Warum nicht einfach die Versionskontrolle des Schemas?

— Alternative

5

@alternative - Mit Migrationen können Sie andere Aufgaben ausführen. Wenn Sie beispielsweise eine Nicht-Null-Spalte hinzufügen müssen, können Sie diese Spalte intelligent mit Daten füllen, anstatt einen Standardwert zu verwenden.

— Josh M.

208

Migrationen bieten Vorwärts- und Rückwärtsschrittänderungen an der Datenbank. In einer Produktionsumgebung müssen während der Bereitstellung inkrementelle Änderungen an der Datenbank vorgenommen werden: Migrationen bieten diese Funktionalität mit einem ausfallsicheren Rollback. Wenn Sie rake db:schema:loadauf einem Produktionsserver ausgeführt werden, werden am Ende alle Ihre Produktionsdaten gelöscht. Dies ist eine gefährliche Angewohnheit.

Abgesehen davon halte ich es für eine anständige Praxis, Migrationen gelegentlich "zusammenzubrechen". Dies beinhaltet das Löschen alter Migrationen, das Ersetzen durch eine einzelne Migration (sehr ähnlich zu Ihrer schema.rbDatei) und das Aktualisieren der schema_migrationsTabelle, um diese Änderung widerzuspiegeln. Seien Sie dabei sehr vorsichtig! Sie können Ihre Produktionsdaten einfach löschen, wenn Sie nicht vorsichtig sind.

Als Randnotiz bin ich der festen Überzeugung, dass Sie die Datenerstellung niemals in die Migrationsdateien aufnehmen sollten. Die seed.rbDatei kann hierfür oder für benutzerdefinierte Rake- oder Bereitstellungsaufgaben verwendet werden. Wenn Sie dies in Migrationsdateien einfügen, wird Ihre Datenbankschemaspezifikation mit Ihrer Datenspezifikation gemischt und es kann zu Konflikten beim Ausführen von Migrationsdateien kommen.

— Jesse Reiss
quelle

80

Vielen Dank für die Information, dass Rake db: schema: load alle Produktionsdaten löscht!

— Magne

2

Anstatt "reduzierte" Migrationen durch eine neue zu ersetzen, die das Schema nachahmt, habe ich ein Juwel geschrieben, das sie nur löscht und Benutzer zur Verwendung auffordert, db:schema:loadwenn sie versuchen, db:migrateeine Neuinstallation durchzuführen . @ clear_migrations

— Yarin

Wahrscheinlich eine offensichtliche Antwort, aber würden Sie vor dem ersten Push-to-Production empfehlen, nur alle Migrationen zu löschen und db.schema als erste Migration zu verwenden?

— dtc

30

Ich bin gerade über diesen Beitrag gestolpert, der vor langer Zeit war und die Antwort, die ich erwartet hatte, nicht gesehen habe.

rake db:schema:loadist großartig, wenn Sie zum ersten Mal ein System in Produktion nehmen. Danach sollten Sie Migrationen normal ausführen.

Dies hilft Ihnen auch dabei, Ihre Migrationen zu bereinigen, wann immer Sie möchten, da das Schema alle Informationen enthält, um andere Maschinen in Produktion zu bringen, selbst wenn Sie Ihre Migrationen bereinigt haben.

— ereslibre
quelle

Sie können Ihre Migrationen also "bereinigen", weil Sie sie nie verwenden müssen? Klingt nach einer bizarren Aussage.

— Abe Petrillo

Mir ist nicht klar, welchen Nutzen es db:schema:loadhat, wenn man sich während des gesamten Entwicklungszyklus nur einmal einige Sekunden lang rasiert. Haben Sie jemals mit einer App gearbeitet, deren Aufbau länger als 30 Sekunden gedauert hat? Ich arbeite derzeit an einer App, deren Migrationsdateien Fehler enthalten, und die niemals migriert wird, ohne dass Fehler behoben oder ausgeführt werden. Dies db:schema:loadlässt mich an Schema denken: Laden ist für den Fall gedacht, dass bei der Entwicklung der App etwas schief gelaufen ist.

— Ninjaxor

Ein weiteres Argument, das ich für die Beibehaltung von Migrationen vorbringen würde, ist, dass das Rails-Kernteam die Benutzer anweist instead of editing schema.rb, please use the migrations feature. Wenn Sie also db:schema:loadeine automatisch generierte Datei ausführen, für die keine Migrationen erneut automatisch generiert werden müssen, können Sie das Schema effektiv manuell "bearbeiten" und Migrationen nicht mehr verwenden. Ich wünschte, ich hätte ein Zitat aus der Rails-Anleitung dazu, aber sie diskutieren nicht schema: load, was meine Frustration bei der Entscheidung, wie ich mich der schema: load-Funktion nähern soll, entmutigend verstärkt. = /

— Ninjaxor

Ich bin genau deshalb auf diese Seite gekommen, weil ich damit einverstanden bin. Ich habe die Erfahrung gemacht, dass es nach der Produktion der Site viel sicherer ist, Migrationen zu verwenden, um sie zu ändern. Trotzdem sagen die Kommentare vom Anfang von db / schema.rb genau das Gegenteil! (Ich habe das Problem zu Beginn jedes Projekts, weil ich vergessen habe, db / schema.rb in den .gitignore zu setzen ...)

— user1251840

@AbePetrillo wow ich habe diese Kommentare komplett verpasst. Natürlich nicht, was ich damit gemeint habe, ist, dass Sie alte Migrationen, die auf allen Produktionsmaschinen ausgeführt wurden, bereinigen können, wenn Sie dies wünschen. Im Laufe der Jahre habe ich sie immer behalten, aber meine Aussage "hilft Ihnen beim Reinigen Ihrer Migrationen, wann immer Sie möchten" bedeutete nicht, dass "ich niemals Migrationen verwenden müsste". Wenn Sie also einen neuen Computer bereitstellen, führen Sie ihn rake db:schema:loadim Gegensatz zu aus rake db:migrate. Dann können Sie von da an rake db:migrate.

— Ereslibre

9

Mit Migrationen können Sie der Datenbank auch Daten hinzufügen. aber db: schema: load lädt nur das Schema.

— Shaunak
quelle

6

Weil Migrationen zurückgesetzt werden können und zusätzliche Funktionen bieten. Wenn Sie beispielsweise einige Daten im Rahmen einer Schemaänderung ändern müssen, müssen Sie dies als Migration tun.

— Jamie Penney
quelle

4

Als Benutzer anderer ORMs kam es mir immer seltsam vor, dass Rails keine Funktion zum Synchronisieren und Aktualisieren hatte. Verwenden Sie also die Schemadatei (die das gesamte aktuelle Schema darstellt), gehen Sie die vorhandene DB-Struktur durch und fügen Sie nach Bedarf Tabellen, Spalten und Indizes hinzu bzw. entfernen Sie sie.

Für mich wäre das viel robuster, wenn auch möglicherweise etwas langsamer.

— Dan James
quelle

1

Die Aufgabe, eine Datenbank mit Daten von einem komplizierten Schema in ein anderes zu migrieren, ist manchmal nicht trivial. Es wird möglicherweise nicht automatisch aufgelöst und Daten werden möglicherweise nicht konsistent in einem Schritt migriert. Die Rails-Migration ist Master und das Schema ist abhängig. Das Schema wird bei jeder Migration automatisch neu erstellt, jedoch nicht umgekehrt.

— Oklahoma

In Rails-eigenen Handbüchern wird ausdrücklich angegeben, dass dies schemader Master und nicht die Migrationen sind.

— Drenmi

0

Ich habe bereits als Kommentar gepostet, halte es jedoch für besser, die Kommentare der Datei db / schema.rb hier abzulegen:

# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended that you check this file into your version control system.

Ich habe die Erfahrung gemacht, dass es besser ist, die Migrationsdateien in git und nicht in die Datei schema.rb zu legen ...

— user1251840
quelle

0

rake db:migrateRichten Sie die Tabellen in der Datenbank ein. Wenn Sie den Migrationsbefehl ausführen, sucht er in db / migrate / nach Ruby-Dateien und führt sie beginnend mit der ältesten aus. Am Anfang jedes Migrationsdateinamens befindet sich ein Zeitstempel.

Im Gegensatz dazu werden rake db:migrateMigrationen ausgeführt, die noch nicht ausgeführt wurden. rake db:schema:loadLädt das bereits generierte Schema db/schema.rbin die Datenbank.

Weitere Informationen zu Rake-Datenbankbefehlen finden Sie hier .

— Nesha Zoric
quelle