Zusammenführen von ActiveRecord-Migrationen außer Betrieb

Question

Sagen wir, ich arbeite in git auf meiner Rails App, und ich habe zwei Zweige, jeder mit ihrer eigenen Migration.

1) branch001 erstellt eine Tabelle tableA über Migration 20160101000000_create_table_A

2) genannt branch002 erstellt eine Tabelle tableB über Migration 20160101000001_create_table_B

Klar, dass die Zeitstempel für die 2. Migration genannt nach die ersten erstellt wurden.

Aber sagen wir, ich fusioniere zuerst branch002 zu master, weil es zuerst fertig ist. Meine Schemadatei wird -

ActiveRecord::Schema.define(version: 20160101000001) do 
    .... 
end 

Das Schema Version erzählt Active es bereits auf ein Niveau/Version größer als mein erster Zweig gepatcht wird.

Was passiert, wenn ich endlich meine erste Filiale zusammenfasse?

1. Wird die Schemaversion auf 20160101000000 zurückgehen?
2. Gibt es Probleme bei der Migration des ersten Zweigs, weil das Schema sieht, dass es bereits "gepatcht" ist und es überspringt?
3. Im Allgemeinen, was ist die beste Praxis für solche Dinge? Soll ich den ersten Zweig mit einem neuen, jüngeren Zeitstempel umbenennen?

Vielen Dank!

EDIT -

wirklich fragen, was ich soll die Zusammenführung Konflikt zu lösen, wenn ich den zweiten Zweig in master verschmelzen. Soll ich es als späteren Zeitstempel belassen oder zum früheren Zeitstempel zurückentwickeln?

<<<<<<< HEAD (master) 
ActiveRecord::Schema.define(version: 20160101000001) do 
======= 
ActiveRecord::Schema.define(version: 20160101000000) do 
>>>>>>> 282cda7... Adding Table B 

Answer 1

Im Falle eines Konflikts sollten Sie die höhere Anzahl der beiden auswählen. Aber was auch immer Sie wählen, es hat keine Auswirkungen auf tatsächliche Migrationen.

Wenn Sie die niedrigere Nummer wählen, wird das nächste Mal, wenn Sie rake db:migrate ausführen, diese Nummer ändern (zu der höheren) und Sie werden Ihre schema.rb und keine Migration ändern. Es ist kein Problem - nur dein Commit wird etwas seltsam sein.

Rails Rake-Task führt alle gefundenen Migrationen aus, die keinen Wert in der Tabelle schema_migrations haben. Und dann nimmt es den höchsten Migrationszeitstempel und setzt diesen Zeitstempel in die schema.rb. Die gesamte Migrationsidee basiert nicht auf einem "neuesten Zeitstempel" (Schemaversion), sondern basiert auf dem Inhalt der Tabelle schema_migrations, die alle Migrationszeitstempel enthält, die bereits ausgeführt wurden. Durch diese Tabelle wird garantiert, dass keine Migration übersprungen wird.

Answer 2

Die sehr kurze Version ist, dass die Dinge in der Regel gut sind: unter der Annahme, dass die Migrationen nicht miteinander interferieren (zB fällt man eine Tabelle, aber die andere nimmt an, dass es noch existiert) sollten Sie keine Probleme bekommen.

Während Ihre Schemadatei eine einzelne Versionsnummer enthält, vergleicht beim Ausführen von Migrationsschienen die Liste der Migrationsdateien mit dem Inhalt der Tabelle schema_migrations und führt alle Migrationen aus, die noch nicht ausgeführt wurden, auch wenn mehr vorhanden sind aktuelle Migrationen, die bereits ausgeführt wurden.

Soweit das Schema Konflikt, persönlich würde ich nur die Migrationen ausführen, die schema.rb neu generieren wird.