Unione di migrazioni di ActiveRecord fuori servizio

Question

Diciamo che sto lavorando su git sulla mia app Rails e che ho due filiali, ciascuna con la propria migrazione.

1) branch001 crea una tabella denominata tableA via migrazione 20160101000000_create_table_A

2) branch002 crea una tabella denominata tableB via migrazione 20160101000001_create_table_B

Chiaramente il timestamp per la 2a migrazione è stato creato dopo il primo.

Ma diciamo che unisco branch002 a master prima perché è pronto prima. Il mio file di schema diventa -

versione

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

Lo schema dice ActiveRecord è già patchato a un livello/Versione maggiore del mio primo ramo.

Cosa succederà quando finalmente riuscirò a fondere il mio primo ramo?

1. La versione dello schema regredirà su 20160101000000?
2. Ci saranno problemi durante l'esecuzione della migrazione del primo ramo perché lo schema vede che è già "aggiornato" e lo ignora?
3. In generale, qual è la procedura migliore per cose come questa? Devo rinominare il primo ramo con un nuovo timestamp più recente?

Grazie!

EDIT -

davvero chiedendo cosa devo fare per risolvere il conflitto di unione quando ho unire il secondo ramo in master. Devo lasciarlo come timestamp più tardi o regredire al timestamp precedente?

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

Answer 1

In caso di conflitto, selezionare il numero più alto di due. Ma qualunque cosa tu scelga, non ha alcun impatto sulle migrazioni effettive.

Se si sceglie il numero inferiore, la volta successiva che si esegue , questo numero verrà modificato (in quello più alto) e si verificherà una modifica nel numero schema.rb e nessuna migrazione. Non è un problema: solo il tuo commit sarà un po 'strano.

L'attività Rails rake esegue tutte le migrazioni rilevate e che non hanno un valore nella tabella schema_migrations. E poi prende il timestamp di migrazione più alto e inserisce questo timestamp nello schema.rb. L'intera idea di migrazione non è basata su un "timestamp più recente" (versione dello schema) ma si basa sul contenuto della tabella schema_migrations che contiene tutti i timestamp di migrazione che è già stato eseguito. Quindi attraverso questa tabella garantisce che nessuna migrazione venga saltata.

Answer 2

La versione molto breve è che di solito le cose vanno bene: supponendo che le migrazioni non interferiscano l'una con l'altra (ad esempio, si abbandona una tabella ma l'altra si presuppone che esista ancora) non si dovrebbe incontrare problemi.

Mentre il file di schema ha un numero di versione singolo al suo interno, quando si eseguono le migrazioni le guide confrontano l'elenco dei file di migrazione con il contenuto della tabella schema_migrations ed eseguono tutte le migrazioni che non sono ancora state eseguite, anche se ci sono più migrazioni recenti che sono già state eseguite.

Per quanto riguarda lo schema di conflitto, personalmente eseguirò semplicemente le migrazioni, che rigenereranno schema.rb.