Perché lo schema.rb cambia (agli occhi di Git) quando si esegue rake db: migrate?

Question

Questo è un po 'di generale, lo so, ma mi sta dando fastidio. Ho lavorato su molti progetti di rotaie in remoto con Git e ogni volta che faccio un git pull e vedo che c'è una sorta di modifica dei dati (migrazione, o schema.rb cambia). Faccio un rake db:migrate.

Questi in genere funzionano bene e posso continuare a lavorare. Ma se fai un git pull e poi git status, la tua directory di lavoro è pulita (ovviamente) quindi fai un rake db:migrate (ovviamente quando ci sono cambiamenti) e un altro git status e all'improvviso il tuo db/schema.rb è cambiato. Ho appena eseguito immediatamente il git checkout per ripristinare l'ultima versione commessa del file schema.rb, ma perché dovrebbe essere necessario ?! Cosa stanno facendo le rotaie? Aggiornamento di un timestamp? Non riesco a capire quale sia la differenza ma forse mi manca qualcosa?

Answer 1

Lo schema consente alle macchine di eseguire rake db:schema:load durante l'installazione per la prima volta invece di dover eseguire le migrazioni, che possono diventare obsolete se i modelli vengono rinominati o rimossi, ecc. Si suppone che vengano aggiornati dopo una migrazione e si desidera sempre ultima versione controllata nel controllo del codice sorgente.

Answer 2

schema.rb riflette lo schema del database in modo tale che quando si esegue la migrazione (con modifiche) si segua che lo schema cambia anche per riflettere la modifica del database. Di solito aggiungo schema.rb al nostro gitignore, insieme a database.yml (probabilmente perché invece di usare schema: carico come quello qui sotto, di solito eseguo un dump sql quando clonato un'applicazione esistente - ma sono solo io)

Answer 3

La fine di db:migrate è scaricare lo schema. Avrà diversi timestamp (git dovrebbe dirti), e diverse versioni di rails/database gemme ti daranno formati leggermente diversi. È un fastidio secondario vederlo tutto il tempo.

vi consiglio di aggiungere schema.rb al file .gitignore.

Answer 4

L'ordine degli attributi nel dump riflette l'ordine degli attributi nel database e che può andare fuori sincrono se una persona ha giocato in locale con le migrazioni, eseguendole in avanti e all'indietro manualmente e modificando le cose in prendili proprio così È possibile creare uno stato in cui l'ordine degli attributi nello schema dello pusher.rb è diverso da quello che vedranno tutti gli altri quando eseguono le migrazioni.

Se è facile ricreare i dati di sviluppo, ricostruire il database da schema.rb - quindi tutti sono di nuovo sincronizzati (ma ricorda che non è possibile ricaricare i dati da un dump SQL che crea anche la tabella - che ricreare il problema, deve essere un dump/carico solo dati). Nel peggiore dei casi, puoi creare una migrazione per eliminare la colonna e un'altra per aggiungerla di nuovo.