schema.rb vermasselt wegen Migrationen in anderen Branchen

Derzeit arbeite ich mit einer riesigen Rails-Anwendung und mehreren Filialen mit jeweils einer neuen Funktion für diese Anwendung. Es passiert viel, ein Feature erfordert Migrationen, was kein Problem sein sollte, bis Sie es mit Master zusammenführen: schema.rb wurde mit den Informationen Ihrer dev-Datenbank aktualisiert!schema.rb vermasselt wegen Migrationen in anderen Branchen

Zur Klarstellung:

1. Branch A has migration create_table_x 
2. Branch B has migration create_table_y 
3. Branch A adds another create_table_z and runs db:migrate 
4. You want to merge Branch A with Master and you see table_x, table_y and table_z in the schema.rb of Branch A.

Es ist keine Option + zurücksetzen die Datenbank in einem Zweig vor jeder Migration Saatgut oder eine Datenbank pro Zweig erstellen. Aufgrund der großen Größe von 2 GB SQL-Daten wäre es nicht praktikabel.

Meine Frage:

Ist es wirklich erforderlich schema.rb im Repository zu halten, da sie jede Migration wieder aufgebaut wird?

Wenn ja, ist es möglich, ein Schema aus den Migrationen anstelle des Datenbank-Dumps zu erstellen?

Quelle

2013-05-08 Vikko

Ich denke, Sie sollten Ihre schema.rb in Ihrem Repository behalten. Es könnte passieren, dass jemand die Migrationsdateien aufräumt und ein paar ungenutzte Migrationen aus der Vergangenheit löscht ... und wenn Sie kein einheitliches Schema haben.rb könnte ich in Unordnung geraten. Die Schemadatei wird bei jeder Migration aktualisiert und nicht vollständig neu erstellt. aber trotzdem eine interessante Frage. – Mattherick

Ja, das Problem ist, dass es von der aktuellen Datenbankstruktur generiert wird, unabhängig davon, ob die Tabellen in der Datenbank in der übergeordneten oder der Zweigstelle, in der Sie sich befinden, hinzugefügt wurden. Das meine ich mit 'neu erstellt'. Ich hoffe, dass jemand einen schöneren Weg kennt, die Datenbank vom Master jedes Mal zu fallen/zu kopieren, wenn Sie einen Zweig mit Migrationen wechseln :) – Vikko

Mögliches Duplikat von [Was ist der bevorzugte Weg, um schema.rb in git zu verwalten?] (Http: // stackoverflow .com/questions/737854/what-is-the-preferred-way-to-manage-schema-rb-in-git) – Tachyons

Sie sollten das Schema in Ihrem Repo behalten. Durch Ausführen der Migration werden Zusammenführungskonflikte innerhalb Ihrer schema.rb-Datei für Sie behoben. meine einfache nehmen Sie Ihre Fragen

Ist es erforderlich? nicht wirklich, aber gute Praxis.

„ist es dringend empfohlen, diese Datei in Ihrer Version Kontrollsystem zu überprüfen.“ -schema.rb

Es ist möglich? Ja, aber Sie können sich fragen, ob Sie wirklich Zeit sparen, indem Sie entweder manuell oder durch Erstellen des Schemas Ihrer Migrationen woanders arbeiten und es einschieben.

Sie ge tthe zusätzlichen Vorteil der Verwendung von

rake db:schema:load

und

rake db:schema:dump

http://tbaggery.com/2010/10/24/reduce-your-rails-schema-conflicts.html

Quelle

2013-06-18 08:13:11

Das Speichern von schema.rb im Repo ist wichtig, weil Sie möchten, dass ein neuer Entwickler (oder Ihre Testumgebung) eine neue Datenbank nur aus schema.rb generieren kann. Bei vielen Migrationen werden möglicherweise nicht alle weiterhin ausgeführt, insbesondere wenn sie Modellklassen verwenden, die nicht vorhanden sind oder sich geändert haben oder andere Gültigkeitsprüfungen als zum Zeitpunkt der ersten Migration aufweisen. Wenn Sie Ihre Tests ausführen, möchten Sie Ihre Datenbank aus schema.rb dumpen und neu erstellen, nicht indem Sie alle Migrationen jedes Mal erneut ausführen, wenn Sie die vollständige Testsuite ausführen.

Wenn Sie gleichzeitig an zwei verschiedenen Feature-Zweigen arbeiten und die Datenbankstruktur in beiden ändern, denke ich, dass schema.rb das kleinste Ihrer Probleme ist. Wenn Sie eine Spalte in Zweig B umbenennen oder entfernen, wird Zweig A immer dann unterbrochen, wenn auf die alte Spalte verwiesen wird. Wenn sie nur neue Tabellen erstellen, ist es nicht so schlimm, aber Sie wollen schema.rb aktualisiert werden, wenn Sie von Master in A zusammenführen, so dass A nicht versucht, die Migration ein zweites Mal auszuführen und scheitern, weil die neue Tabelle bereits existiert.

Wenn das Ihre Frage nicht beantwortet, könnten Sie vielleicht Ihren Workflow ein wenig mehr erklären?

Quelle

2013-05-08 15:23:27 sockmonk

Das ist richtig, aber Sie wollen nicht die Tabellen von Zweig B (wo Sie ausgeführt haben Migrationen) werden im Master angezeigt, BEVOR Sie Zweig B zusammenführen. Zum Beispiel: Wenn es eine Tabelle gibt, die in Zweig A und Zweig B verwendet wird, ändert ** Zweig B den Namen in Nachname **, ** Zweig A ändert die Initialen in Vorname**. Sie fÃ¼hren Zweig A zusammen, Sie fÃ¼hren Zweig B nicht zusammen, da es einige Komplikationen hat => das ** generierte Schema enthÃ¤lt Vorname und Nachname **, wÃ¤hrend Sie lieber ** Vorname und Name ** haben mÃ¶chten. Eine Logik mag es sein, nach Migrationen zu suchen, die nicht in master sind, und sie im schema zurückzusetzen. Rb – Vikko

Das klingt zunächst gut, aber einige Migrationen sind möglicherweise nicht so reversibel. Sie könnten dies wahrscheinlich manuell über: rake db: migrate VERSION = 123 erreichen, wobei 123 die Migrationsnummer in Ihrem schema.rb ist. Das sollte nach Bedarf entweder vorwärts oder rückwärts migrieren, um zu dieser Version zu gelangen. Letztendlich wird Ihre beste Wette sein, mindestens die Migrationen von jedem Zweig, der zum Master zusammengeführt wird, zum frühestmöglichen Zeitpunkt zu bekommen, selbst wenn Sie es durch Rosinenpicken machen müssen. – sockmonk

Ich bin mir dessen bewusst, aber das Problem ist mit etwa 20 Branchen zu arbeiten, die alle ein Leben zwischen ein paar Stunden und ein paar Monaten haben. Dort kommt die Komplikationen: Sie vergessen, der Zweig hatte Migrationen und Sie sind geschraubt ! Außerdem dauert die Migration auf einem großen Tisch (über 100.000 Einträge) ewig. Sie sollten sie lieber für die Entwicklung dort belassen und nur das Schema aktualisieren, wenn die Tabelle in Ihrem aktuellen Zweig nicht verwendet wird. – Vikko

Frische Temporary DB als eine schnelle Abhilfe

Zum Beispiel die folgenden Schritte aus wann immer du müssen ziemlich db/schema.rb auf bestimmten Zweig:

git checkout - db/schema.rb
Schalter auf die unterschiedlichen Entwicklungsdatenbank, dh aktualisieren config/database.yml
rake db: Drop & & rake db : setup
rake db: migrate
begehen Ihre ziemlich db/schema.rb
Änderungen in der Konfigurations zufällt/database.yaml

Quelle

2015-05-11 20:38:47 wik

schema.rb vermasselt wegen Migrationen in anderen Branchen

Antwort

Verwandte Themen