Do I have to "rake db:migrate" all the time when I committed fully migrated repository in github?
For example, I committed the rails repository in c9.io to github.
It was fully "rake db:migrate"d and didn't need to migrate.
But when I cloned my github repository and executed it,
there was a problem that " hasn't been migrated and you need to rake db:migrate"
I want to know what "really rake db:migrate" meaning in rails
and why cloned repo does need "rake db:migrate" all the time
rake:db migrate runs all the migrations that should be run and changes your db/schema.rb file. When you clone your repository, you add different migration files, so Rails demand you to execute the command again.
Related
Previously i had deleted some migration files,which caused missing relations error(while tying to deploy to new server) so to fix that i added back the deleted migration files.I committed and pushed the new changes to gitlab after which i tried cap production deploy and still getting the missing relation error .On checking he release folder in the server i found that newly added back migrations files were not present.How to fix this.
I thought of trying to manually create the files in server,but cap production deploy is creating new release folders each time
how to fix this
I solved this issue by executing the following commands inside server release folder
1)
I ran
RAILS_ENV=production bundle exec rails db:reset DISABLE_DATABASE_ENVIRONMENT_CHECK=1 --trace
2) RAILS_ENV=production bundle exec rails db:setup DISABLE_DATABASE_ENVIRONMENT_CHECK=1
3)After this i executed cap production deploy and it all seems good
Note1: try executing the above commands first without DISABLE_DATABASE_ENVIRONMENT_CHECK=1 --trace if prompted add this command
Note2: In case u had some migration files deleted and currently u are trying to deploy to new server,then even if cap production deploy fails with missing relation error(caused by deleted migrations) you can get inside the latest release folder and run above commands to get the database setup correctly,after which u can try cap production deploy which most probably wont show any issues(related to deleted migration files)
I was told that I should follow the below steps if make new migrations in my branch and have merge conflicts with master in the db/structure.sql file.
In the branch, bundle exec rake db:drop
In the branch, bundle exec rake db:create
In master, bundle exec rake db:structure:load
In the branch, git merge master
In the branch, bundle exec rake db:migrate
What are steps 1-3 necessary if all I want to do is align the db/structure.sql file? By merging in master, don't I get the new migrations I haven't ran yet and then by running them, it will update my db/structure.sql?
You're right, dropping and recreating the database to solve a conflict in db/structure.sql (or db/schema.rb for that matter) is a little ridiculous. You should be able to simply run the new migrations and get an updated structure.sql from the db:migrate.
The db/stucture.sql file is simply the database's structure as the database sees it (whereas db/schema.rb is the database's structure in the limited view of it that ActiveRecord has). If there is a conflict in structure.sql, that simply means:
The merge involves new migrations which change the database structure.
The branch you're merging in has run the migrations in a different order so the schema's don't quite match up even though they may be functionally equivalent.
(1) is solved by running the new migrations and possibly fixing any places where the migrations themselves are in conflict. A quick bin/rake db:migrate should fix this and leave you with a new non-conflicted db/structure.sql.
(2) is solved the same way. You could also do a a manual bin/rake db:structure:dump to rebuild db/structure.sql but you'd only do this if you're certain that you really do have this situation; but really, db:migrate will take care of it so there's no reason not to just db:migrate.
Conflicts in db/structure.sql (or db/schema.rb) don't indicate a problem with the db/structure.sql itself, they indicate problems with the database that git can't directly see. The solution to the conflicts is to fix the database.
You can just run bundle exec rake db:structure:dump to re-generate the db/structure.sql file.
For schema.rb I found https://stackoverflow.com/a/3815807/6003161
I am having an odd Heroku problem. I successfully pushed to Heroku with a new seed file and I saw the changes go through, and this seed file just has one Item.create in it. The old seed file has 10000 creates in it. The seeding should be very quick. So far, I:
1) Made sure that I pushed from master to heroku master. I ran git push heroku master from master
2) I made sure to git add and git commit.
3) When I run heroku run rake db:seed, it still runs like this 100000 line seed file. Any ideas on what might be going on?
Did you reset the database in heroku before updating the seed file? If not, run
$ heroku pg:reset DATABASE
$ heroku run rake db:migrate
$ heroku run rake db:seed
This removes the previous seed from the production database first.
I have an app that is working fine locally. At one point I tried installed the Act As Taggable gem, which generated a series of migration files. Now I rolled back locally after we voted against using that gem - but after deploying to heroku, it looks like 5 of these migration files did upload to heroku.
I then ran
`heroku run rake db:migrate'
I am now receiving this error
'uninitialized constant AddTaggingsCounterCacheToTags::ActsAsTaggableOn/app/db/migrate/20141107010718_add_taggings_counter_cache_to_tags.acts_as_taggable_on_engine.rb:6:in `up'
Now I don't need the "AddTaggingsCounterCacheToTags" but I definitely need a migration that was supposed to run after this.
Any tips on how I can remove this from the production/heroku server? How I can remove only specific migrations and keep the newest migration I made?
Thanks!
Okay folks. I got it.
The problem was that after I removed the files locally, they were still present on git. The process was to remove the migration that was causing the error and then I could have all migrations after come through just fine. Commands are below...
git rm [filename]
git commit -a -m "removed the migrations causing the error from git too"
git push origin master
git push heroku master
heroku run rake db:migrate
There is an issue with having an empty/unnecessary table in the database now, but the important thing is - I can continue to add migrations and my newest features are now working properly on production!
Cheers!
I have multiple branches each with a migration file. So when I checkout a branch, I do a db:migrate and it would in turn update my schema.rb file.
But, when I checkout another branch and run rake db:migrate, Ideally the changes made my the migration in the previous branch should be removed from schema.rb and the details of the new migration should get into schema.rb
This doesn't happen.
So, I did a rake db:rollback STEP=5, when I checked out a new branch and then did a db:migrate. Even now, I have table details of the migration in previous branch. What I am I doing wrong ? Or is this how Rails behaves?
All performed migrations are saved in table schema_migrations (migration timestamp is saved in DB). When you run rake db:migrate Rails parses directory db/migrate and finds files which are not presented in the table (it compares by timestamp).
Let's you have you have 10 migrations in branch master - schema_migrations has 10 records with timestamps. You create a new branch from master branch_1, create and run there a new migration. Your table schema_migrations has 11 records.
You go back to master and run rake db:migrate - Rails will do NOTHING because no new files are found (in db/migrate). When you run rake db:rollback STEP=5 I suppose (I have never checked it) Rails rollback 5 last migrations from branch MASTER. And it's logical because the last migration (made in branch_1) doesn't exist in branch master (the file with code exists only in branch_1!). So you can't rollback DB changes made in branch_1 from branch master.
What todo?!
I see several strategies:
1) checkout to branch_1 and run rake db:rollback STEP=N (N >= count of new migrations) (You can rollback more migrations then you performed in this branch). Checkout back to master and run rake db:migrate (to perform migrations from master)
2) when you have production dump or good seeds.
Drop current DB, load dump (or seeds), run rake db:migrate
(As for me it is the simplest way when you have production dump!)
PS Maybe smbd else suggest other way to get correct DB in current branch