ChatGPT解决这个技术问题 Extra ChatGPT

Purge or recreate a Ruby on Rails database

I have a dev Ruby on Rails database full of data. I want to delete everything and rebuild the database. I'm thinking of using something like:

rake db:recreate

Is this possible?

I'd suggest looking past the highest-upvoted answer. In my opinion rake db:drop db:create db:schema:load might be more appropriate than rake db:drop db:create db:migrate (although I'm ready to be wrong about that).
rake db:drop db:create db:migrate
db:drop + db:create + db:migrate == db:migrate:reset. I usually resort to db:schema:load, when migrations are broken. I rarely need to recreate database, so speed doesn't matter much. Also, if you have unapplied migrations, db:schema:load and db:reset won't apply them. Not sure if that's much of an argument.

A
Andrew Hendrie

I know two ways to do this:

This will reset your database and reload your current schema with all:

rake db:reset db:migrate

This will destroy your db and then create it and then migrate your current schema:

rake db:drop db:create db:migrate

All data will be lost in both scenarios.


It seems rake db:reset also runs all migrations (at least on Rails 3), so that should be all that is needed, right?
Or, rather, it leaves the schema identical to what running all the migrations would have. But the migrations aren't run per se (so if you have migrations which insert data, that won't happen; for this, you should really use a db/seeds.rb file).
I know that for Tracks GTD app db:migrate didn't work. I had to do db:reset when moving from Sqlite3 to Postgres.
You'll also need to run rake db:test:prepare for testing, or else you'll get an error like: Could not find table 'things' (ActiveRecord::StatementInvalid)
Someone should make clear that rake db:reset and rake db:drop db:create db:migrate do two whole different things. The latter wipes out the whole app database, recreates it and then goes through every migration to update the schema (db/schema.rb or db/structure.sql), but does not fill it with seed data. The first instead is an alias for rake db:drop db:schema:load db:seed, so it wipes out the whole app database but it does not update the schema, and then populates with seed data. So, if you haven't changed anything in your migrations, the first is quicker, the latter is safer.
E
Eneko Alonso

On Rails 4, all needed is

$ rake db:schema:load

That would delete the entire contents on your DB and recreate the schema from your schema.rb file, without having to apply all migrations one by one.


works for rails 3 as well. useful for when you just messed up your test database and want to reset it to a working version that matches your dev db
Thanks for this. I didn't realize that db:drop and db:create were redundant.
This doesn't updates the schema, is not a safe way if you refactor your migrations.
Make sure that schema is up to date. Sometimes people commit migration files but skip committing the changes to the schema.rb file because they dont realize what it means.
@ClaudioFloreani refactoring migrations is asking for trouble. Once they're run, they should be left alone, permanently.
d
de-russification

I use the following one liner in Terminal.

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

I put this as a shell alias and named it remigrate

By now, you can easily "chain" Rails tasks:

$ 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+

That's going to run all of your migrations one after the other, which isn't scalable and is error-prone. Also, I'm pretty sure db:migrate updates your schema.rb, so your schema:dump isn't doing anything useful.
so how does one empty the database? in development... clear it all out.
@AnApprentice You can run db:reset, which is just a Google (or check on the Guides) away. My comment wasn't to advise against using that, but to avoid using db:migrate when what you really want is db:schema:load.
By the way, @TK, you really don't need to run all of these as separate processes dependent on the exit status of the last. Instead, just pass all desired tasks to rake, like so: rake db:drop db:create db:schema:load.
It's anecdotal, but I've never had an issue running db:migrate... whereas db:schema:load is sensitive to someone forgetting to check schema.rb into version control alongside a new migration.
N
NM Pennypacker

Update: In Rails 5, this command will be accessible through this command:

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

As of the newest rails 4.2 release you can now run:

rake db:purge 

Source: 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

It can be used together like mentioned above:

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

As @bekicot says in plainer english db:purge "remove all the data but preserve all the table and columns"
@MCB I was wrong, sory about that, db:purge is not preserving the tables.
c
coreyward

Depending on what you're wanting, you can use…

rake db:create

…to build the database from scratch from config/database.yml, or…

rake db:schema:load

…to build the database from scratch from your schema.rb file.


You've got to drop the database first…or you can just delete the tables if you prefer.
+1 for schema load. sometimes migrations get messed up, but the schema should be what is kept intact.
I read in The Rails 3 Way that loading the schema is the way to go, as opposed to running all the migrations. I don't remember exactly what their reasoning was but it seems to make sense. If the end result is the same either way, it seems simpler and less error-prone just to load the database from the schema than to run a bunch of migrations.
The reasoning is that migrations are meant to migrate data, and become increasingly brittle over time as your models change. You can (and should) bake in bare-minimum scoped models into your migrations whenever feasible to ensure they run, but this just doesn't scale well and is much less efficient than just building the database from what the application knows is the final point. Why rely on migrations to create a database that looks like your schema when you can just build from the blueprint itself?
e
eebbesen

From the command line run

rake db:migrate:reset

this is the only way that makes the app to run all migrations again. Because each migration makes changes to schema.rb and if you only drop and create, migrate will do nothing (tested on rails 6)
M
Manish Shrivastava

Use like

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

All in one line. This is faster since the environment doesn't get reloaded again and again.

db:drop - will drop database.

db:create - will create database (host/db/password will be taken from config/database.yml)

db:migrate - will run existing migrations from directory (db/migration/.rb)*.

db:seed - will run seed data possible from directory (db/migration/seed.rb)..

I usually prefer:

rake db:reset

to do all at once.

Cheers!


I like to add db:test:prepare to this, for good measure. This depends, of course, on whether or not you're testing.
db:reset == db:drop + db:schema:load + db:seed, db:migrate:reset == db:drop + db:create + db:migrate
M
Mario Pérez Alarcón

In Rails 6 there is a convenient way for resetting DB and planting seeds again:

rails db:seed:replant # Truncates tables of each database for current environment and loads the seeds

https://weblog.rubyonrails.org/2019/3/15/this-week-in-rails-security-fixes-bulk-insert-and-upsert-seeds-replanting/


М
Малъ Скрылевъ

Just issue the sequence of the steps: drop the database, then re-create it again, migrate data, and if you have seeds, sow the database:

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

Since the default environment for rake is development, in case if you see the exception in spec tests, you should re-create db for the test environment as follows:

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

In most cases the test database is being sowed during the test procedures, so db:seed task action isn't required to be passed. Otherwise, you shall to prepare the database:

rake db:test:prepare

or

RAILS_ENV=test rake db:seed

Additionally, to use the recreate task you can add into Rakefile the following code:

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

Then issue:

rake db:recreate

E
Erik Trautman

You can manually do:

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

Or just rake db:reset, which will run the above steps but will also run your db/seeds.rb file.

An added nuance is that rake db:reset loads directly from your schema.rb file as opposed to running all the migrations files again.

You data gets blown away in all cases.


P
Pawel

You can use this following command line:

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

K
Kush

To drop a particular database, you can do this on rails console:

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

And then migrate DB again

$bundle exec rake db:migrate 

Y
Yana Agun Siswanto

On rails 4.2, to remove all data but preserve the database

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

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


Well... Just tried it, but it does not preserve tables and columns. You have to run a db:migrate after having run a db:purge. So this does not preserve tables and columns. It does however preserve the database itself so you do not have to db:create
@Cedric You are right, db:purge is not preserve the table. I updated the code.
A
Aleksandr Babak

You can use db:reset - for run db:drop and db:setup or db:migrate:reset - which runs db:drop, db:create and db:migrate.

dependent at you want to use exist schema.rb


V
Victor

According to Rails guide, this one liner should be used because it would load from the schema.rb instead of reloading the migration files one by one:

rake db:reset

O
Obed Lorisson

Because in development , you will always want to recreate the database,you can define a rake task in your lib/tasks folder like that.

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

and in terminal you will run

rake db:all

it will rebuild your database


T
Thorin

I think the best way to run this command:

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

T
Touseef Murtaza

Simply you can run

rake db:setup

It will drop database, create new database and populate db from seed if you created seed file with some data.


m
marc_s

3 options, same result:

1. All steps:

  $ 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. Reset:

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

3. Migrate:reset:

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

Notes:

If schema:load is used is faster than doing all migrations, but same result.

All data will be lost.

You can run multiple rakes in one line.

Works with rails 3.


p
port5432

I've today made quite a few changes to my rails schema. I realised I needed an additional two models in a hierarchy and some others to be deleted. There were many little changes required to the models and controllers.

I added the two new models and created them, using:

rake db:migrate

Then I edited the schema.rb file. I manually removed the old models that were no longer required, changed the foreign key field as required and just reordered it a bit to make it clearer to me. I deleted all the migrations, and then re-ran the build via:

rake db:reset

It worked perfectly. All the data has to be reloaded, of course. Rails realised the migrations had been deleted and reset the high-water mark:

-- assume_migrated_upto_version(20121026094813, ["/Users/sean/rails/f4/db/migrate"])

d
davidauza.engineer

I use:

rails db:drop to delete the databases.

rails db:create to create the databases based on config/database.yml

The previous commands may be replaced with rails db:reset.

Don't forget to run rails db:migrate to run the migrations.