Menu
I ran "rake db:migrate" to re-sync schema.db with my database schema. But it failed, saying that one of my tables already exists. I think it was trying to re-create the table. If you just want to get schema.rb updated to reflected any changes you made in the database independently of Rails, what command should you use if not "rake db:migrate"? And what's the best source of documentation on this type of thing?
684
A migration means that you move from the current version to a newer version (as is said in the first answer). Using rake db:migrate you can apply any new changes to your schema. But if you want to rollback to a previous migration you can use rake db:rollback to nullify your new changes if they are incorrectly defined.
When you run db:migrate, rails will check a special table in the database which contains the timestamp of the last migration applied to the database. It will then apply all of the migrations with timestamps after that date and update the database table with the timestamp of the last migration.
db:reset: Resets your database using your migrations for the current environment. It does this by running the db:drop , db:create , db:migrate tasks. db:rollback: Rolls the schema back to the previous version, undoing the migration that you just ran. If you want to undo previous n migrations, pass STEP=n to this task.
To check for status, run rails db:migrate:status . Then you'll have a good view of the migrations you want to remove. Then, run rails db:rollback to revert the changes one by one. After doing so, you can check the status again to be fully confident.
"rake db:migrate" will try and run all the outstanding migrations for your project. If you just want to dump the schema do a "rake db:schema:dump".
But I think you have a problem where it says that the table already exists. One of your migrations is failing because the table it is trying to add already exists in your db. Did you create one by hand? Did you down a migration, but not have a down written for it? You will need to fix this before you can write future migrations. If it is just a mistake, and the table is there and correct and you want to ignore this. My recommendation is to hack around it by commenting out the create table in the failing migration. Then run "rake db:migrate". Then but the create table back. This will update your schema version.
Make sure you write proper downs on all migrations.
119
Try
RAILS_ENV=development rake db:drop
before
RAILS_ENV=development rake db:migrate
and be happy!
Making sure that you run it on your test or development environment since this will drop the database/tables
21
I've found that occasionally, when things get a little weird, you'll find yourself in a situation where Rails will want to run a migration that it ought rightly to be considering already done (the table already exists, etc). You can mark a migration as done by finding its number (the number part at the beginning of the filename), going into mysql and issuing a query like so:
insert into schema_migrations values('20090521153438');
(or whatever the number of your migration is)
Or if it's a plugin migration being run using Desert's migrate_plugin:
insert into plugin_schema_migrations values('my_plugin', '005');
rake db:migrate:reset will drop all your tables, run all the migrations and create a new schema.rb file.
27
Try rake db:schema:dump or rake db:migrate:redo.
28
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
