Perché rake sta lanciando questo errore di migrazione di Rails?

Question

Ho due macchine ... una macchina di sviluppo e una macchina di produzione. Quando ho portato la mia app rails sul server di produzione per la prima volta, non ho avuto problemi. Ho semplicemente importato schema.rb eseguendo rake db: schema: load RAILS_ENV = production. Tutto andava bene.

Quindi, sulla mia macchina di sviluppo, ho apportato alcune modifiche e un'altra migrazione, quindi ho copiato la nuova applicazione sulla macchina di produzione. Ho quindi provato ad aggiornare il database eseguendo rake db: migrate RAILS_ENV = production. Ottengo il seguente errore: " Esiste già un oggetto chiamato "schema_migrations" nel database. "

Sto pensando a me stesso, non stai scherzando Rake ... l'hai creato tu! Ho tracciato il rastrello e sembra che il rastrello pensi che sia la prima volta che corre. Tuttavia, analizzando la mia tabella "schema_migrations" sulla mia macchina di sviluppo e sulla mia macchina di produzione, puoi vedere che c'è una differenza di una migrazione, cioè quella che voglio migrare.

Ho anche provato a definire esplicitamente il numero di versione, ma non funziona neanche.

Qualche idea su come posso aggiornare il mio server di produzione?

Aggiornamento:

Vorrei iniziare dicendo che non posso semplicemente "eliminare" il database. È un server di produzione con già oltre 100.000 record. Cosa succede se si verifica un problema simile in futuro? Devo semplicemente eliminare la tabella ogni volta che si verifica un problema con il database? Potrebbe funzionare questa volta, ma non sembra una soluzione pratica a lungo termine per ogni problema del database. Dubito che il problema che sto riscontrando ora sia unico per me.

1. Sembra che la tabella 'schema_info' e la tabella 'schema_migrations' siano uguali. Nella mia configurazione, ho solo "schemi_migrations". Come affermato in precedenza, la differenza tra la tabella "schema_migrations" sul server di produzione e la macchina di sviluppo è solo un record. Cioè, il record contenente il numero di versione della modifica che voglio migrare.

2. Dal libro che ho letto, "Simply Rails 2", si afferma che quando si passa per la prima volta a un server di produzione, invece di eseguire rake db: migrate, si dovrebbe semplicemente eseguire rake: db: schema: load.

3. Se è importante, sto usando Rails versione 2.1.

Answer 1

Questa è un'ipotesi, lo ammetto: penso che, poiché hai eseguito per la prima volta db: schema: load invece di db: migrare nel tuo ambiente di produzione, hai la struttura del tuo db, ma non i dati che migrano popolano nel tuo tabella schema_info. Quindi ora, quando esegui la migrazione nell'ambiente di produzione, non ci sono dati in schema_info ed è per questo che Migrate ritiene che non sia ancora stata eseguita (perché non lo è).

Detto questo ... dici che hai guardato in " schema_migrations " tabella, e che c'è una differenza tra una versione e lo sviluppo dalla produzione ... Non ho sentito parlare di quella tabella, anche se sono indietro di qualche mese sulla mia versione delle rotaie. Forse potresti provare a creare un " schema_info " tabella nell'ambiente di produzione, con un'unica "versione" e aggiungi una riga con la versione in cui ritieni che l'ambiente di produzione sia attivo.

Answer 2

Se ottieni " Esiste già un oggetto chiamato "schemi_migrations" nel database. " messaggio di errore quindi sospetto che tu stia utilizzando MS SQL Server come database? (Poiché questo sembra un messaggio di errore di MS SQL Server)

Se sì, quale adattatore per database ActiveRecord stai usando? (Qual è il tuo file database.yml, quali gemme hai installato per accedere al database MS SQL Server?)

Attualmente sembra che Rails non trovi la tabella schema_migrations nello schema di produzione e quindi cerchi di crearla e questa creazione fallisce con un messaggio di errore del database. Probabilmente il motivo sono i caratteri maiuscoli / minuscoli nel nome della tabella schema_migrations - per quanto ho capito, gli identificatori di MS SQL Server fanno distinzione tra maiuscole e minuscole.

Answer 3

A seconda del sistema utilizzato in produzione, ho visto casi in cui non funziona:

rake db:migrate RAILS_ENV=production

Ma dove funziona:

RAILS_ENV=production rake db:migrate

Eccentrico, lo so, ma vale la pena provarlo per vedere se fa la differenza.

Answer 4

Per quanto riguarda l'aggiornamento:

1. Non capisco quale sia la differenza tra la tua produzione schema_migrations e la versione dev. C'è un record in entrambe le tabelle (dovrebbe esserci solo 1 colonna, "versione", giusto) o c'è un singolo record nel DB di sviluppo e zero record in produzione? Se nella tabella di produzione sono presenti zero record, procedere come segue:

   ActiveRecord :: Base.connection.execute (" INSERT schema_migrations (versione) VALUES (# {il mio numero di versione su cui si suppone che la produzione sia}) ")

2. In alternativa, puoi provare a eliminare completamente la tabella schema_migrations durante la produzione:

   ActiveRecord :: Base.connection.execute (" DROP TABLE schema_migrations ")

   Quindi, rieseguendo rake db: migrate RAILS_ENV = production . Ciò eseguirà le migrazioni a partire dalla versione 1, che probabilmente non è ciò che stai cercando.

3. In alternativa, puoi avviare una sessione IRB nel tuo ambiente di produzione, fare una richiesta " " o "carica" (Non ricordo mai quale, o se è importante) del file di migrazione che desideri caricare, quindi chiama MyMigrationClass.up . Dovresti impostare manualmente il numero di versione nella tabella schema_migrations dopo, dato che avresti ancora il problema in futuro, ma come un tipo di hack rapido, funzionerebbe.

Answer 5

Vorrei semplicemente rilasciare il DB, aggiungerlo di nuovo ed eseguire rake rb: migrate. Brad ha ragione nel dire che quando hai eseguito il caricamento dello schema, non ha inserito alcun record nella tabella schema_migrations.

Questo è ovviamente più complicato se ci sono dati che non si possono perdere sul server di produzione. Potresti ottenere le attività di backup del rake (non sei sicuro che faccia parte o meno del core) e quindi eseguire rake db: backup: scrivi sul database di produzione, quindi dopo aver aggiornato le migrazioni sulla produzione, esegui rake db: backup:. lettura

Answer 6

schema_info proviene da una vecchia versione di Rails. schema_migrations è il nuovo figlio sul blocco. Dovresti essere in grado di rimuovere la tabella schema_info in quanto non verrà più utilizzata. Probabilmente vorrai cercare eventuali problemi associati a questa modifica del nome.

Answer 7

rake db: schema: load caricherà la struttura del database da schema.rb. Questo file è la rappresentazione corrente della struttura del database. Viene utilizzato quando si dispone di uno schema vuoto (database) che richiede la creazione di tutte le tabelle e gli indici. Ti evita di dover eseguire tutte le migrazioni. Se si dispone di un database di produzione esistente con dati inseriti, non si desidera eseguirlo. Come altri hanno già detto, sarebbe male!

Answer 8

So che questo post è stato un po 'di tempo fa, ma mi sono imbattuto in esso e non è stato davvero risposto. Come viene fuori su Google, ecco qui.

Quando hai eseguito un rastrello db: schema: dump (o quando questo è stato fatto per te dagli script di build) avrà messo la definizione della tabella delle migrazioni in schema.rb. Alla fine dello script, il processo proverà a creare nuovamente la tabella, ma ovviamente esiste già. Rimuovere la tabella delle migrazioni da schema.rb prima di eseguire rake: schema: load e non verrà visualizzato alcun messaggio di errore.

Dovrai impostare il numero di versione nella tabella delle migrazioni per eseguire successivamente le migrazioni. Quindi è importante sapere a quale versione si riferisce anche il tuo schema.rb o eliminare tutte le vecchie migrazioni (sono al sicuro nel tuo SCM giusto?)

Answer 9

rake db:migrate RAILS_ENV=production

Utilizza l'attività db: schema: load solo per la prima creazione, è necessario migrare le modifiche incrementali.