I would like to remove/delete a migration file. How would I go about doing that? I know there are similar questions on here but as an update, is there a better way than doing script/destroy?
Also, should I do a db:reset or db:drop if I remove/delete a migration?
I usually:
Perform a rake db:migrate VERSION=XXX on all environments, to the version before the one I want to delete.
Delete the migration file manually.
If there are pending migrations (i.e., the migration I removed was not the last one), I just perform a new rake db:migrate again.
If your application is already on production or staging, it's safer to just write another migration that destroys your table or columns.
Another great reference for migrations is: http://guides.rubyonrails.org/migrations.html
Another way to delete the migration:
$ rails d migration SameMigrationNameAsUsedToGenerate
Use it before rake db:migrate is executed because changes in database will stay forever :) - or remove changes in Database manually
Run below commands from app's home directory:
rake db:migrate:down VERSION="20140311142212" (here version is the timestamp prepended by rails when migration was created. This action will revert DB changes due to this migration)
Run "rails destroy migration migration_name" (migration_name is the one use chose while creating migration. Remove "timestamp_" from your migration file name to get it)
None of these answers quite fit the problem i had as the migration i wanted to delete was missing:
I had created and run a migration in some other branch, which was then discarded. The problem is when a migration is run, rails adds the version into a schema_migrations table in the database. So even if it isn't listed in your db structure or schema, rails looks for it.
You can reveal these orphaned migrations by running:
rails db:migrate:status
Note the versions of the missing migrations and head into the db console:
rails dbconsole
Now remove the versions from the migration table manually:
delete from schema_migrations where version='<version>';
You should now be good.
You can also run a down migration like so:
rake db:migrate:down VERSION=versionnumber
Refer to the Ruby on Rails guide on migrations for more info.
We can use,
$ rails d migration table_name
Which will delete the migration.
Sometimes I found myself deleting the migration file and then deleting the corresponding entry on the table schema_migrations from the database. Not pretty but it works.
This also works in Rails 5.
If the migration was the most recent one you can remove the database column(s) that the migration added by doing:
rake db:rollback
then remove the migration file itself by running:
rails d migration WhateverYourMigrationWasNamed.rb
Look at 4.1 Rolling Back
http://guides.rubyonrails.org/migrations.html
$ rake db:rollback
I just had this same problem:
rails d migration fuu
-this deleted the migration with the last timestamp
rails d migration fuu
-this deleted the other migration
use git status to check that is not on the untracked files anymore
rails g migration fuu
That fixed it for me
Side Note:
Starting at rails 5.0.0
rake has been changed to rails
So perform the following
rails db:migrate VERSION=0
Related
I have recently in my project needed to erase my databases and using rails g migrate DropTable. This has worked in making me deleting the schema, but now when I run rails db:migrate the schema does not repopulate with the db/migrate information. I am kind of stuck here. How should I go about filling up my schema.
Try to the following rake or rails, make sure your file exists under the db/migrate then take TIMESTAMP number from file name then run like below
rake db:migrate:up VERSION=20171212082249 #=> 20171212082249 that mean TIMESTAMP number from file name under the db/migrate
or
rake db:migrate:redo VERSION=20171212082249 # that will run the down and then the up step
You can see this article for more explanation.
Additional
rake db:rollback STEP=1
This will roll back lost one migration, if you need to rollback specific one from many then try this
rake db:migrate:down VERSION=TIMESTAMP #=> TIMESTAMP mean 20171212082249 this number from your migrated file name
I'm currently following the ruby on rails tutorial: http://guides.rubyonrails.org/getting_started.html.
I am trying to save data into the database. However, when I run: rails server I get the following error:
Migrations are pending. To resolve this issue, run: bin/rake db:migrate RAILS_ENV=development
I've looked at the other articles and when I run:
bin/rake db:migrate
I get a rake aborted!
After running:
rake db:abort_if_pending_migrations....
I see that:
You have 1 pending migration:
20150805200129 CreateDatabases
SQLite3::SQLException: table "databases" already exists:
and it just tells me to run rake db:migrate to start again.
It seems that it already exists. Is there a way to cancel the pending migration?
Sometimes, even dropping a local development database is not a good idea.
There are better ways to delete/destroy a specific migration in your Rails application.
You could use rails d migration command to destroy a particular migration:
rails d migration MigrationName
To undo the changes corresponding to a particular migration, you can use db:migrate:down method like this:
rake db:migrate:down VERSION=XXX
Sometimes, things could get more messy and in those situation another handy thing is to take a look at the schema_migrations table in your database which has all the migrations with their version saved in it.
You can delete a particular migration from this table like this:
delete from schema_migrations WHERE version = VERSION;
if you don't want that migration to be present anymore.
Your migration may have failed midway (so it created the table, but didn't finish).
You are just using development environment, so it's okay to just drop the database and rebuild it from scratch:
rake db:drop # THIS WILL DELETE YOUR DATABASE
rake db:create
rake db:migrate
If you are like me and maintain your database structure outside of Rails, you can just delete the migration file from db/migration. I got the error in the OP's question when I used the rails generate command to create a model class, forgetting that it also creates a migration file.
Do not use this method if you rely on Rails to maintain your database structure!
I keep my Rails structure file up to date by building it from the database using:
bundle exec rake db:structure:dump
I do not encourage to drop the database and start from the beginning especially when you already have the data inside the database.
My approach to this will be migrate first, then rollback. After that you can safely delete the migration file. So the procedure is as following.
rails db:migrate
rails db rollback
rm db/migrate/your_last_migration_file.rb
You can recreate database and run all migrations in your development environment with such command
rails db:migrate:reset
If you want to revert the wrong migrations, You can drop the whole db using this:
rake db:drop
Then remove the migrations file manually(This wont corrupt the db when you recreate as the Schema migrations would be dropped as well).
Then run
rake db:migrate
And if there is data to be seeded, then run this as well
rake db:setup
Hello I am new to rails.
I am working with an existing postgres db. I would like to create CRUD for all of the tables.
I've started with:
rails g scaffold firstTableName
Then I start rails:
rails s
When I navigate to localhost:3000/firstTableName, rails gives the following error:
Migrations are pending; run 'bin/rake db:migrate RAILS_ENV=development' to resolve this issue.
I thought that 'rake db:migrate' was only for setting up your database. My db is already set up. If I run 'rake db:migrate', then I get an error that firstTableName already exists.
Please Help me understand how to make rails happy.
Thank you.
the error is because you already have the table firstTableName is already present and as you did scaffold, it will create the model, controller and view for you, so it has also create the migration for the firstTableName.
If you already have the migration in place try skipping the migration while scaffolding
rails g scaffold firstTableName --skip-migration
Your database should have a table named schema_migrations with only one column version. Then you should write all migration versions into that table by hands.
Migrations placed in project_root/db/migrate/, and the вшпшеы in the file name is the same as version migration.
When you run migrations rails keeps track of these by matching each migration in db/migrate folder with an entry in schema_migrations table that includes timestamp for all the migrations that rails has already run for that environment in versions column.
Reason is to allow you to migrate incrementally.
Earlier versions of rails had a strong philosophy of having a down migration as well to go back in time. However, that has been left as a choice now.
Your complaint is because it was not able to create schema_migrations table. My suggestion is to allow it to do so by running rake db:migrate on a fresh db.
If you have data in the tables on this instance run it on another database and then just copy across the versions table.
http://guides.rubyonrails.org/migrations.html
I had just installed devise so the table didn't have any data on it except one user (me).
I was re-doing the database all over again so I dropped it all. I did rails g scaffold to generate 6 new models and controllers and did rake db:migrate
In my /db/migrate directory I have the devise file with the filename 20130603211907_devise_create_users.rb
Here is the issue: If I do rake db:migrate:down VERSION=20130603211907 it will delete all the new migrations.
How do I run a migration again, without deleting all the newer migrations?
It will run the down and then the up step (This command can drop your table!):
rake db:migrate:redo VERSION=xxxxxxx
To prevent your table from being deleted you could do this in conjunction with commenting out the down step temporarily.
Thanks for the help everyone. This is what worked for me:
WARNING: these commands will delete all data in your database!
rake db:drop
rake db:create
rake db:migrate
rake db:migrate:up VERSION=20090408054532
this will migrate all file upto VERSION=20090408054532
checkout Run a single migration file
If you are developing locally and it wouldn't hurt to remove all data from your models you could simply drop your db and then create & migrate from scratch:
Purge or recreate a Ruby on Rails database
You can call rake db:migrate:redo VERSION=20130603211907 which will rerun the specified version.
Also, if you have migrations that should only run when going up the migration chain (e.g. data transformation, copying, etc.), you can specify a
def up
do_something
end
and def down (going down), def change (both ways) method respectively.
To temporarily disable migrations, just, for example, rename the method def up to def up_ and it will be ignored when processing the migration chain.
I have created a migration file for creating a table UserDetails in my db.. and it was working fine b4...
Unknowingly I deleted that table to do some modification .. But now when i gave
rake db:migrate .. its not creating the table ..
I have the migration file .. BUt when i give rake db:migrate its not creating.. How to do so ??
Rails maintains a 'schema_migrations' table to know what migrations have already run and will not run the migrations that have already been completed. Since, you had already run the migration once, it would have updated the 'schema_migrations' table with the version no. of the migration. You can do rake db:rollback to revert the last migration run or rake db:migrate:down VERSION=<version_number> to revert any migration that was run before.
Now, I suggest if you know the version no (Time stamp of the file), you can manually delete from 'schema_migrations' table and re-run db:migrate.
Rake stores the time of the most recent migration inside the database - if the migration you're trying to run is older than that, it won't run with rake db:migrate.
I don't know how to run a specific migration manually, sorry :/
Could you just run that specific migration as stated in the Guides. http://guides.rubyonrails.org/migrations.html#being-specific
I have run specific migrations by their timestamp before. It seems like it would work in this situation also.