rake db: schema: load vs. migrations

171

Domanda molto semplice qui: se le migrazioni possono diventare lente e ingombranti man mano che un'app diventa più complessa e se invece abbiamo le rake db:schema:loadchiamate più pulite da chiamare, perché esistono migrazioni?

Se la risposta a quanto sopra è che le migrazioni vengono utilizzate per il controllo della versione (una registrazione graduale delle modifiche al database), quindi quando un'app diventa più complessa e rake db:schema:loadviene invece utilizzata di più, continuano a mantenere la loro funzione principale?

Attenzione:

Dalle risposte a questa domanda: rake db:schema:load eliminerà i dati su un server di produzione, quindi fai attenzione quando lo usi.

ruby-on-rails ruby-on-rails-3 migration

— sscirrus
fonte

5

+1 Non ho mai capito lo scopo delle migrazioni; perché non solo la versione controlla lo schema?

— alternativa

5

@alternative: le migrazioni ti consentono di fare altre cose, come se hai bisogno di aggiungere una colonna non nulla, puoi riempire in modo intelligente quella colonna con i dati invece di usare un valore predefinito.

— Josh M.,

208

Le migrazioni forniscono modifiche al passo avanti e indietro al database. In un ambiente di produzione, è necessario apportare modifiche incrementali al database durante le distribuzioni: le migrazioni forniscono a questa funzionalità un rollback fail-safe. Se si esegue rake db:schema:loadsu un server di produzione, si finirà per eliminare tutti i dati di produzione. Questa è un'abitudine pericolosa da affrontare.

Detto questo, credo che sia una pratica decente occasionalmente "far crollare" le migrazioni. Ciò comporta l'eliminazione delle migrazioni precedenti, la loro sostituzione con una singola migrazione (molto simile al schema.rbfile) e l'aggiornamento della schema_migrationstabella per riflettere questa modifica. Fai molta attenzione quando lo fai! Puoi eliminare facilmente i tuoi dati di produzione se non stai attento.

Come nota a margine, credo fermamente che non si dovrebbe mai mettere la creazione di dati nei file di migrazione. Il seed.rbfile può essere utilizzato per questo, oppure attività di rake o deploy personalizzate. Inserendo questo nei file di migrazione si mescolano le specifiche dello schema del database con le specifiche dei dati e possono verificarsi conflitti durante l'esecuzione dei file di migrazione.

— Jesse Reiss
fonte

80

grazie per aver informato che rake db: schema: load elimina tutti i dati di produzione!

— Magne

2

Invece di sostituire le migrazioni "collassate" con una nuova che imita lo schema, ho scritto una gemma che le cancella e richiede agli utenti di utilizzare db:schema:loadse provano a eseguire db:migrateuna nuova installazione. @ clear_migrations

— Yarin,

probabilmente una risposta ovvia ma prima della prima spinta alla produzione, consiglieresti di eliminare tutte le migrazioni e di utilizzare db.schema come prima migrazione?

— dtc,

30

Mi sono appena imbattuto in questo post, molto tempo fa e non ho visto la risposta che mi aspettavo.

rake db:schema:loadè fantastico per la prima volta che si mette in produzione un sistema. Successivamente, dovresti eseguire le migrazioni normalmente.

Questo ti aiuta anche a ripulire le tue migrazioni quando vuoi, poiché lo schema ha tutte le informazioni per mettere in produzione altre macchine anche quando hai ripulito le tue migrazioni.

— ereslibre
fonte

Quindi puoi "ripulire" le tue migrazioni perché non devi mai usarle? Sembra un'affermazione bizzarra.

— Abe Petrillo,

Non mi è chiaro quale sia il beneficio di db:schema:loaddiverso dalla rasatura di pochi secondi una volta durante il ciclo di sviluppo. Hai mai lavorato con un'app che ha richiesto più di 30 secondi per essere costruita? Attualmente sto lavorando su un'app che ha dei bug nei suoi file di migrazione e non migrerà mai senza avere correzioni di bug o in esecuzione, il db:schema:loadche mi fa pensare allo schema: il carico è per quando qualcosa è andato storto riguardo allo sviluppo dell'app.

— Ninjaxor,

Un altro argomento che vorrei sollevare per mantenere le migrazioni è che il core team di Rails indirizza gli utenti instead of editing schema.rb, please use the migrations feature. Quindi, se stai eseguendo db:schema:loadun file generato automaticamente che non hai migrazioni da generare di nuovo automaticamente, stai effettivamente seguendo la strada della "modifica" manuale dello schema e del disuso delle migrazioni. Vorrei avere una citazione dalla guida delle rotaie su questo, ma non discutono di schema: load, che aggiunge scoraggiante alla mia frustrazione nel decidere come affrontare lo schema: funzione di caricamento. = /

— Ninjaxor il

Sono venuto a questa pagina proprio perché sono d'accordo con quello. La mia esperienza è che una volta che il sito è in produzione, è molto più sicuro usare le migrazioni per cambiarlo. Nonostante ciò, i commenti dell'inizio di db / schema.rb affermano esattamente il contrario! (Ho il problema all'inizio di ogni progetto perché dimentico di inserire db / schema.rb in .gitignore ...)

— user1251840

@AbePetrillo Eeeek !!! mi sono perso completamente questi commenti. Ovviamente no, ciò che intendevo è che puoi pulire le vecchie migrazioni che sono state eseguite su tutte le macchine di produzione, se lo desideri. Nel corso degli anni li ho sempre tenuti in giro, ma la mia dichiarazione "ti aiuta a ripulire le tue migrazioni quando vuoi" non significava che "non avrei mai dovuto usare le migrazioni". Quindi, quando si distribuisce una nuova macchina, eseguire rake db:schema:loadinvece di rake db:migrate. Quindi da lì in poi, puoi rake db:migrate.

— ereslibre,

9

Le migrazioni ti consentono di aggiungere dati anche al db. ma db: schema: load carica solo lo schema.

— Shaunak
fonte

6

Perché le migrazioni possono essere ripristinate e fornire funzionalità aggiuntive. Ad esempio, se è necessario modificare alcuni dati come parte di una modifica dello schema, è necessario farlo come migrazione.

— Jamie Penney
fonte

4

Come utente di altri ORM, mi è sempre sembrato strano che Rails non avesse una funzione di "sincronizzazione e aggiornamento". cioè, usando il file di schema (che rappresenta l'intero schema aggiornato), passare attraverso la struttura del DB esistente e aggiungere / rimuovere tabelle, colonne, indici come richiesto.

Per me questo sarebbe molto più robusto, anche se forse un po 'più lento.

— Dan James
fonte

1

L'attività di migrazione del database con dati da uno schema complicato a un altro non è banale a volte. Potrebbe non essere risolto automaticamente e i dati potrebbero non essere migrati in modo coerente con un solo passaggio. La migrazione delle rotaie è master e lo schema dipende. Lo schema viene ricreato automaticamente con ogni migrazione, ma non viceversa.

— Oklas,

Le guide di Rails affermano esplicitamente che schemaè il master, non le migrazioni.

— Drenmi,

0

Ho già pubblicato come commento, ma è meglio inserire qui i commenti del file db / schema.rb:

# Note that this schema.rb definition is the authoritative source for your
# database schema. If you need to create the application database on another
# system, you should be using db:schema:load, not running all the migrations
# from scratch. The latter is a flawed and unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for issues).
#
# It's strongly recommended that you check this file into your version control system.

In realtà, la mia esperienza è che è meglio mettere i file di migrazione in git e non nel file schema.rb ...

— user1251840
fonte

0

rake db:migrateimposta le tabelle nel database. Quando esegui il comando di migrazione, cercherà in db / migrate / eventuali file ruby ed eseguirli a partire dal più vecchio. C'è un timestamp all'inizio di ogni nome file di migrazione.

Diversamente da rake db:migratequello che esegue migrazioni non ancora eseguite, rake db:schema:loadcarica lo schema già generato nel db/schema.rbdatabase.

Puoi trovare ulteriori informazioni sui comandi del database rake qui .

— Nesha Zoric
fonte