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.