schema.rb incasinato a causa di migrazioni in altri rami

Question

Attualmente sto lavorando con un'applicazione di rotaie enorme e più rami con ciascuna una nuova funzionalità per questa applicazione. Succede molto che una funzionalità richiederà migrazioni, il che non dovrebbe essere un problema finché non lo si fonde con master: schema.rb è stato aggiornato con le informazioni del proprio database di sviluppo!

per chiarire:

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. 

Non è un'opzione per ripristinare + seminare il database prima di ogni migrazione in un ramo o di creare un database per ogni ramo. A causa dell'enorme dimensione dei dati SQL da 2 GB, non sarebbe fattibile.

La mia domanda:

E 'davvero necessario per mantenere schema.rb nel repository dal momento che viene ricostruito ogni migrazione?

In tal caso, è possibile creare uno schema fuori dalle migrazioni anziché dal dump del database?

Answer 1

si dovrebbe mantenere lo schema all'interno del repository. l'esecuzione della migrazione risolverà i conflitti di unione all'interno del file schema.rb. la mia semplice risposta alle tue domande

1. È necessario? non proprio, ma buone pratiche.

"E 'fortemente raccomandato di controllare questo file nel vostro sistema di controllo versione ." -schema.rb

1. E 'possibile? Sì, ma potresti chiederti se davvero risparmi in qualsiasi momento, manualmente o costruendo lo schema dalle tue migrazioni altrove e spingendolo dentro.

si ge lLa vantaggio di utilizzare

rake db:schema:load 

e

rake db:schema:dump 

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

Answer 2

Mantenere schema.rb nel repository è importante, perché si desidera che un nuovo sviluppatore (o l'ambiente di test) sia in grado di generare un nuovo database solo da schema.rb. Quando si eseguono molte migrazioni, è possibile che non tutte continuino a essere eseguite, soprattutto se si basano su classi di modelli che non esistono o sono state modificate o che hanno validità diverse rispetto a quando è stata eseguita la prima migrazione. Quando si eseguono i test, si desidera scaricare e ricreare il database da schema.rb, non eseguendo nuovamente tutte le migrazioni ogni volta che si esegue la suite di test completa.

Se si stanno lavorando contemporaneamente su due diverse feature branch e si modifica la struttura del database in entrambi, penso che schema.rb sia l'ultimo dei problemi. Se rinomini o rimuovi una colonna nel ramo B, il ramo A si interromperà ogni volta che fa riferimento alla vecchia colonna. Se tutto ciò che stanno facendo è creare nuove tabelle, non è così male, ma poi tu vuoi che lo schema.rb sia aggiornato quando ti unisci dal master in A, così che A non prova ad eseguire la migrazione una seconda volta e falliscono perché la nuova tabella esiste già.

Se questo non risponde alla tua domanda, potresti spiegare un po 'di più il tuo flusso di lavoro?

Answer 3

fresco Temporary DB come una rapida soluzione

Ad esempio, effettuare le seguenti operazioni ogni volta che si bisogno di abbastanza db/schema.rb sul ramo particolare:

1. git checkout - db/schema.rb
2. interruttore al diverso database di sviluppo, vale a dire l'aggiornamento config/database.yml
3. rake db: Goccia & & rake db : impostazione
4. rake db: migrate
5. commettere il tuo bel db/schema.rb
6. annullare le modifiche in config/database.yaml