Elimina o ricrea un database Ruby on Rails


582

Ho un database di Ruby on Rails pieno di dati. Voglio eliminare tutto e ricostruire il database. Sto pensando di usare qualcosa come:

rake db:recreate

È possibile?


Suggerirei di guardare oltre la risposta più votata. Secondo me rake db:drop db:create db:schema:loadpotrebbe essere più appropriato di rake db:drop db:create db:migrate(anche se sono pronto a sbagliarmi al riguardo).
Jason Swett,


2
rake db:drop db:create db:migrate
William Hampshire,

db:drop + db:create + db:migrate == db:migrate:reset. Di solito ricorro a db:schema:loadquando le migrazioni sono interrotte. Raramente ho bisogno di ricreare il database, quindi la velocità non ha molta importanza. Inoltre, se hai migrazioni non applicate db:schema:loade db:resetnon le applichi. Non sono sicuro se questo è molto argomento.
x-yuri,

Risposte:


1074

Conosco due modi per farlo:

Ciò ripristinerà il tuo database e ricaricherà lo schema corrente con tutti:

rake db:reset db:migrate

Questo distruggerà il tuo db e quindi lo creerà e quindi migrerà lo schema corrente:

rake db:drop db:create db:migrate

Tutti i dati andranno persi in entrambi gli scenari.


36
Sembra che rake db:resetesegua anche tutte le migrazioni (almeno su Rails 3), quindi dovrebbe essere tutto ciò che è necessario, giusto?
plindberg,

1
O meglio, lascia lo schema identico a quello che avrebbe in esecuzione tutte le migrazioni. Ma le migrazioni non vengono eseguite di per sé (quindi se hai migrazioni che inseriscono dati, ciò non accadrà; per questo, dovresti davvero usare un file db / seeds.rb).
plindberg,

1
So che per Tracks GTD app db: migrare non ha funzionato. Ho dovuto fare db: resettare quando mi sono spostato da Sqlite3 a Postgres.
labirinto

11
Dovrai anche eseguire il rake db:test:preparetest, altrimenti riceverai un errore del tipo:Could not find table 'things' (ActiveRecord::StatementInvalid)
s2t2,

31
Qualcuno dovrebbe chiarirlo rake db:resete rake db:drop db:create db:migrate fare due cose completamente diverse . Quest'ultimo cancella l'intero database dell'app, lo ricrea e quindi passa attraverso ogni migrazione per aggiornare lo schema ( db/schema.rbo db/structure.sql), ma non lo riempie di dati seed. Il primo invece è un alias per rake db:drop db:schema:load db:seed, quindi cancella l'intero database dell'app ma non aggiorna lo schema e quindi popola con i dati seed. Quindi, se non hai cambiato nulla nelle tue migrazioni, la prima è più veloce, la seconda è più sicura.
Claudio Floreani,

157

Su Rails 4, tutto ciò che serve è

$ rake db:schema:load

Ciò eliminerebbe l'intero contenuto sul tuo DB e ricreare lo schema dal tuo file schema.rb, senza dover applicare tutte le migrazioni una per una.


6
funziona anche per rotaie 3. utile per quando hai appena incasinato il tuo database di test e vuoi ripristinarlo a una versione funzionante che corrisponda al tuo dev db
bigpotato

Grazie per questo. Non me ne rendevo conto db:droped ero db:createridondante.
Grant Birchmeier,

3
Questo non aggiorna lo schema, non è un modo sicuro se si esegue il refactoring delle migrazioni.
Claudio Floreani,

questa è la risposta migliore per me
roxdurazo,

2
@ClaudioFloreani refactoring migrations chiede problemi. Una volta eseguiti, dovrebbero essere lasciati soli, permanentemente.
nrowegt,

45

Uso il seguente liner nel Terminal.

$ rake db:drop && rake db:create && rake db:migrate && rake db:schema:dump && rake db:test:prepare

L'ho messo come alias di shell e l'ho chiamato remigrate

Ormai, puoi facilmente "concatenare" le attività di Rails:

$ rake db:drop db:create db:migrate db:schema:dump db:test:prepare # db:test:prepare no longer available since Rails 4.1.0.rc1+

12
Eseguiranno tutte le migrazioni una dopo l'altra, il che non è scalabile ed è soggetto a errori. Inoltre, sono abbastanza sicuro che db: migrate aggiorna il tuo schema.rb, quindi il tuo schema: dump non sta facendo nulla di utile.
coreyward

quindi come si svuota il database? in sviluppo ... cancella tutto.
AnApprentice

3
@AnApprentice Puoi correre db:reset, che è solo un Google (o controlla le Guide ) di distanza. Il mio commento non è stato di sconsigliarlo, ma di evitare di usarlo db:migratequando lo desideri davvero db:schema:load.
coreyward il

7
A proposito, @TK, in realtà non è necessario eseguire tutti questi come processi separati dipendenti dallo stato di uscita dell'ultimo. Invece, basta passare tutte le attività desiderate per rake, in questo modo: rake db:drop db:create db:schema:load.
coreyward il

1
È aneddotico, ma non ho mai avuto problemi con l'esecuzione db:migrate... mentre db:schema:loadè sensibile a qualcuno che dimentica di controllare schema.rb nel controllo della versione insieme a una nuova migrazione.
johncip,

37

Aggiornamento: in Rails 5, questo comando sarà accessibile tramite questo comando:

rails db:purge db:create db:migrate RAILS_ENV=test


Dalla versione 4.2 di rails più recente è ora possibile eseguire:

rake db:purge 

Fonte: commit

# desc "Empty the database from DATABASE_URL or config/database.yml for the current RAILS_ENV (use db:drop:all to drop all databases in the config). Without RAILS_ENV it defaults to purging the development and test databases."
  task :purge => [:load_config] do
    ActiveRecord::Tasks::DatabaseTasks.purge_current
  end

Può essere usato insieme come menzionato sopra:

rake db:purge db:create db:migrate RAILS_ENV=test

Come dice @bekicot in inglese semplice db:purge"rimuovi tutti i dati ma conserva tutta la tabella e le colonne"
MCB

@MCB Avevo torto, sory a riguardo, db:purge non sta preservando le tabelle.
Yana Agun Siswanto,

29

A seconda di cosa desideri, puoi usare ...

rake db:create

... per creare il database da zero config/database.ymlo ...

rake db:schema:load

... per creare il database da zero dal tuo schema.rbfile.


1
Devi prima eliminare il database ... oppure puoi semplicemente eliminare le tabelle se preferisci.
coreyward

5
+1 per il caricamento dello schema. a volte le migrazioni vengono incasinate, ma lo schema dovrebbe essere quello che viene mantenuto intatto.
Danny,

Ho letto in The Rails 3 Way che il caricamento dello schema è la strada da percorrere, invece di eseguire tutte le migrazioni. Non ricordo esattamente quale fosse il loro ragionamento, ma sembra avere senso. Se il risultato finale è lo stesso in entrambi i casi, sembra più semplice e meno soggetto a errori solo caricare il database dallo schema piuttosto che eseguire un gruppo di migrazioni.
Jason Swett,

3
Il ragionamento è che le migrazioni hanno lo scopo di migrare i dati e diventare sempre più fragili nel tempo man mano che i modelli cambiano. Puoi (e dovresti) inserire modelli con ambito minimo nelle migrazioni ogni volta che è possibile assicurarne l'esecuzione, ma questo non si adatta bene ed è molto meno efficiente della semplice creazione del database da quello che l'applicazione sa essere il punto finale . Perché affidarsi alle migrazioni per creare un database che assomigli al tuo schema quando puoi semplicemente costruire dal modello stesso?
coreyward

13

Dalla riga di comando eseguito

rake db:migrate:reset

questo è l'unico modo che consente all'app di eseguire nuovamente tutte le migrazioni. Poiché ogni migrazione apporta modifiche schema.rbe se si solo drope create, migratenon farà nulla (testato su rotaie 6)
shampoo

12

Usa come

rake db:drop db:create db:migrate db:seed

Tutto in una riga. Questo è più veloce poiché l'ambiente non viene ricaricato più e più volte.

db: drop - eliminerà il database.

db: create - creerà il database (host / db / password sarà preso da config / database.yml)

db: migrate - eseguirà le migrazioni esistenti dalla directory (db / migration / .rb) *.

db: seed - eseguirà i dati seed possibili dalla directory (db / migration / seed.rb) ..

Di solito preferisco:

rake db:reset

fare tutto in una volta.

Saluti!


1
Mi piace aggiungere db: test: preparati a questo, per una buona misura. Questo dipende, ovviamente, dal fatto che tu stia testando o meno.
ctc,

db:reset == db:drop + db:schema:load + db:seed,db:migrate:reset == db:drop + db:create + db:migrate
x-yuri,

11

Emettere semplicemente la sequenza dei passaggi: rilasciare il database, quindi ricrearlo di nuovo, migrare i dati e, se si dispone di seed, seminare il database:

rake db:drop db:create db:migrate db:seed

Poiché l'ambiente predefinito per rakeè sviluppo , nel caso in cui si veda l'eccezione nei test delle specifiche, è necessario ricreare db per l' ambiente di test come segue:

RAILS_ENV=test rake db:drop db:create db:migrate

Nella maggior parte dei casi il database di test viene seminato durante le procedure di test, quindi db:seednon è necessario passare l'azione dell'attività. In caso contrario, è necessario preparare il database:

rake db:test:prepare

o

RAILS_ENV=test rake db:seed

Inoltre, per utilizzare l' attività di ricreazione è possibile aggiungere in Rakefile il seguente codice:

namespace :db do
   task :recreate => [ :drop, :create, :migrate ] do
      if ENV[ 'RAILS_ENV' ] !~ /test|cucumber/
         Rake::Task[ 'db:seed' ].invoke
      end
   end
end

Quindi rilasciare:

rake db:recreate

8

Puoi fare manualmente:

rake db:drop
rake db:create
rake db:migrate

O semplicemente rake db:reset, che eseguirà i passaggi precedenti ma eseguirà anche il tuo db/seeds.rbfile.

Una sfumatura aggiunta è che si rake db:resetcarica direttamente dal tuo schema.rbfile anziché eseguire nuovamente tutti i file delle migrazioni.

I tuoi dati vengono spazzati via in tutti i casi.


6

È possibile utilizzare questa seguente riga di comando:

rake db:drop db:create db:migrate db:seed db:test:clone

4

Per eliminare un determinato database, è possibile farlo sulla console di rails:

$rails console
Loading development environment
1.9.3 > ActiveRecord::Migration.drop_table(:<table_name>)
1.9.3 > exit

E quindi migrare di nuovo DB

$bundle exec rake db:migrate 

4

Su rotaie 4.2, per rimuovere tutti i dati ma preservare il database

$ bin/rake db:purge && bin/rake db:schema:load

https://github.com/rails/rails/blob/4-2-stable/activerecord/CHANGELOG.md


Bene ... Ho appena provato, ma non conserva tabelle e colonne. Devi eseguire un db: migrate dopo aver eseguito un db: purge. Quindi questo non conserva tabelle e colonne. Conserva tuttavia il database stesso, quindi non è necessario db: create
Freddo

1
@Cedric Hai ragione, db: l'eliminazione non conserva la tabella. Ho aggiornato il codice.
Yana Agun Siswanto,

3

Puoi usare db:reset- per eseguire db: drop e db: setup o db:migrate:reset- che esegue db: drop, db: create e db: migrate.

dipende da voi che volete usare esiste schema.rb


2

Secondo la guida di Rails , questo liner dovrebbe essere usato perché si caricava schema.rbinvece di ricaricare i file di migrazione uno per uno:

rake db:reset

1

Poiché in fase di sviluppo, vorrai sempre ricreare il database, puoi definire un'attività di rake nella cartella lib / task in quel modo.

  namespace :db do
      task :all => [:environment, :drop, :create, :migrate] do
   end 
end

e nel terminal correrai

rake db:all

ricostruirà il tuo database


1

Penso che il modo migliore per eseguire questo comando:

**rake db:reset** it does db:drop, db:setup
 rake db:setup does db:create, db:schema:load, db:seed

1

Puoi semplicemente correre

rake db:setup

Rilascerà il database, creerà un nuovo database e popolerà db dal seed se hai creato il file seed con alcuni dati.


1

3 opzioni, stesso risultato:

1. Tutti i passaggi:

  $ rake db:drop           # deletes the database for the current env
  $ rake db:create         # creates the database for the current env
  $ rake db:schema:load    # loads the schema already generated from schema.rb / erases data
  $ rake db:seed           # seed with initial data

2. Ripristina:

  $ rake db:reset          # drop / schema:load / seed

3. Migrare: ripristinare:

  $ rake db:migrate:reset  # drop / create / migrate
  $ rake db:seed

Appunti:

  • Se schema: viene utilizzato il caricamento è più veloce rispetto a tutte le migrazioni, ma lo stesso risultato.
  • Tutti i dati andranno persi.
  • È possibile eseguire più rake in una riga.
  • Funziona con rotaie 3.

0

Oggi ho apportato alcune modifiche al mio schema di binari. Mi sono reso conto che avevo bisogno di altri due modelli in una gerarchia e alcuni altri da eliminare. Ci sono stati molti piccoli cambiamenti richiesti ai modelli e ai controller.

Ho aggiunto i due nuovi modelli e li ho creati, usando:

rake db:migrate

Quindi ho modificato il file schema.rb. Ho rimosso manualmente i vecchi modelli che non erano più necessari, ho modificato il campo chiave esterna come richiesto e l'ho riordinato un po 'per renderlo più chiaro. Ho eliminato tutte le migrazioni e quindi ho rieseguito la build tramite:

rake db:reset

Ha funzionato perfettamente. Tutti i dati devono essere ricaricati, ovviamente. Rails si rese conto che le migrazioni erano state eliminate e ripristinava il limite massimo:

-- assume_migrated_upto_version(20121026094813, ["/Users/sean/rails/f4/db/migrate"])
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.