rebase Rails migrazioni in un progetto a lungo in esecuzione

Question

In questo intendo "ribasamento" nel dizionario, piuttosto che la definizione git ...

Ho una grande, lunga in esecuzione del progetto Rails che ha circa 250 migrazioni, si sta facendo un tocco poco maneggevole per gestire tutti questi.

Detto questo, ho bisogno di una base da cui eliminare e ricostruire il mio database durante l'esecuzione dei test. Quindi i dati contenuti in questi sono importanti.

Qualcuno ha delle strategie per dire, scaricando lo schema in un determinato momento - archiviando tutte le vecchie migrazioni e ricominciando da capo con nuove migrazioni.

Ovviamente posso utilizzare lo schema rake: dump - ma in realtà ho bisogno di un modo che db: migrate caricherà prima lo schema e poi inizierà a eseguire il resto delle migrazioni.

Vorrei continuare a utilizzare le migrazioni poiché sono molto utili per lo sviluppo, tuttavia non è possibile tornare indietro e modificare una migrazione dal 2007, quindi sembra stupido mantenerla.

Answer 1

In generale, non è necessario eliminare le migrazioni precedenti. Se esegui db: esegui la migrazione da zero (nessun db esistente), Rails utilizza db/schema.rb per creare le tabelle anziché eseguire ogni migrazione. In caso contrario, esegue solo le migrazioni necessarie per l'aggiornamento dallo schema corrente al più recente.

Se si vuole ancora combinare le migrazioni fino ad un certo punto in una sola, si potrebbe provare a:

• migrare da zero fino allo schema mirato utilizzando rake db:migrate VERSION=xxx
• scaricare lo schema utilizzando rake db:schema:dump
• rimuovere le migrazioni dall'inizio fino alla versione xxx e creare una singola nuova migrazione utilizzando il contenuto di db/schema.rb (inserire le istruzioni create_table e add_index nel metodo self.up della nuova migrazione).

Assicurarsi di scegliere uno dei vecchi numeri di versione della migrazione per la nuova migrazione aggregata; in caso contrario, Rails tenterebbe di applicare tale migrazione sul proprio server di produzione (che cancellerebbe i dati esistenti, poiché le istruzioni create_table utilizzano: force⇒true).

In ogni caso, non consiglierei di farlo poiché Rails di solito gestisce le migrazioni da sé. Ma se lo vuoi ancora, assicurati di ricontrollare tutto e provare prima localmente prima di rischiare la perdita di dati sul tuo server di produzione.

Answer 2

In aggiunta alla risposta fornita (che indica bene come consolidare il volume delle migrazioni), si indica un problema di eliminazione dei dati (che presumo venga aggiunto manualmente dopo che le fixture hanno popolato le tabelle); che ti infastidisce in base all'aggiornamento di uno stato iniziale dei dati. Alcuni progetti richiedono infatti un intenso affinamento dei dati di base, la ricostruzione e la ricomposizione delle tabelle. La nostra dipende in gran parte dall'esecuzione ripetitiva di queste operazioni, e ho scoperto che se si riesce a ridurre lo schema interamente alle istruzioni execute di SQL, le tabelle verranno ricostruite molto più rapidamente di quanto non facciano con la sintassi di Ruby.

Un ulteriore aiuto banale a ricostruire le tabelle è di dedicare una finestra di terminale separato per una singola istruzione di comando combinato:

rake db: goccia db: creare db: schema: carico db: infissi: carico

Ogni volta che è necessario ricostruire e ri-popolare le tabelle, una pressione su tasto freccia e ritorno restituirà il lavoro di routine. Se non ci sono conflitti nelle istruzioni di esecuzione SQL e se non si hanno ulteriori migrazioni da eseguire mentre il progetto è in stato di sviluppo, le istruzioni SQL verranno eseguite forse meglio del doppio della sintassi Ruby. Le nostre tabelle vengono ricostruite e ri-popolate in 20 secondi in questo modo, ad esempio, mentre la sintassi Ruby aumenta il processo per oltre 50 secondi. Se stai aspettando che i dati si aggiornino per eseguire ulteriori operazioni (soprattutto molte volte), questo fa un'enorme differenza nel flusso di lavoro.

Answer 3

per automatizzare la fusione (o schiacciamento) delle migrazioni, è possibile utilizzare il Squasher gem

Basta installare

gem install squasher 

e correre con una data, e migrazioni prima di tale data verranno uniti:

squasher 2016 # => Will merge all migration created before 2016 

Maggiori dettagli in the README