On subsequent attempts, it is a good idea to first run db:test:prepare, as it first checks for pending migrations and warns you appropriately. Basically it handles cloning the database so you don't have to run the migrations against test to update the test database.
The rake db:migrate above runs any pending migrations on the development environment and updates db/schema.rb. The rake db:test:load recreates the test database from the current db/schema.rb. On subsequent attempts, it is a good idea to first run db:test:prepare, as it first checks for pending migrations and warns you appropriately.
-- http://guides.rubyonrails.org/testing.html
Basically it handles cloning the database so you don't have to run the migrations against test to update the test database.
Specifically, rake db:test:prepare
will do the following:
That is, it will look your db/schema.rb
file to determine if any migrations that exist in your project that have not been run. Assuming there are no outstanding migrations, it will then empty the database and reload it based on the contents of the db/schema.rb
file.
rake db:test:prepare is a good solution for PG issues like this.
“PG::UndefinedTable: ERROR: relation does not exist” with a correct Rails naming and convention" where I couldn't just execute rake db:migrate RAILS_ENV=production
When, for example you can't create test database for a bug discussed here: "PG undefinedtable error relation users does not exist"
All arround this error "PG::UndefinedTable: ERROR: relation xxxxx does not exist”
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With