I just merged a branch and ran rake db:migrate on staging and it reverted all my migrations. (instead of migrating the new one)
I then went back to master, reloaded the db and ran migrations and again, the db got wiped out as before.
Any tips on how to debug that?
Why would db:migrate even rollback any migrations?
Any tips on how to maybe use a different command which tells rails only to grab new migrations and do up and will never roll back any migrations?
If a VERSION environment variable is set then rails will migrate to that version rather than the latest. In particular since rails calls to_i it will migrate to version 0 if it contains a non integer value. You can check this by running env (to list all environment variables) or (echo $VERSION)
This is largely a relic from when rake didn't support passing arguments to tasks on the command line so people use to emulate them with environment variables so that you could do
rake db:migrate VERSION=xyz
Related
I have a ruby on rails application already running in production. The database has records which I do not want to loose. I had to add and run new migrations to add some new columns to existing tables. The migrations run successfully and the schema.rb file reflects the changes but the changes do not appear in the database or existing table structure.
Based on research online, rake db:schema:load updates the db based on the schema.rb file. But this resets the database.
It is crucial that I do not loose the data in the tables.Is there any way to solve this? I am fairly new to ruby on rails.
I was able to fix it. I checked the status of migrations in the production environment rake db:migrate:status RAILS_ENV=production and realised they were down. I then run rake db:migrate RAILS_ENV=production and that did it. Changes now reflect in the db. Thanks #muistooshort for the nudge in the right direction
I recently started using Rails, and created a few Models using the CLI which in turn created some migrations.
I ran the rake db:migrate command after adding all my columns in there, and then realized that I'd left out the associations.
So what did I do?
I went ahead and edited the migrations to include those keys.
I ran rake db:migrate again, and nothing changed in the schema.
Then I ran rake db:reset and then rake db:setup.
When that didn't work, I deleted my schema.rb (the darn thing wouldn't get updated!) and tried recreating it. When I realized that didn't work, I dropped the database, and killed the schema.
Now I'm stuck with some manually modified migrations, no schema.rb and no database.
How do I get the modified migrations to generate a schema, and play nice with Rails?
In development it does not matter to drop and rebuild your database. I do it often and I even have a rake task for that. The 3 command to chain are:
rake db:drop
rake db:create
rake db:migrate
# And a 4rth optional command to rebuild your test database
rake db:test:prepare
With this you should be good
Next time you need to modify a migration manually after migrating it, you should process by:
rake db:rollback
edit your migration
rake db:migrate
Following those steps will save you some headaches
Bonus info:
After you deployed your migration to your production server you cannot manually modify it, hence you must write another migration that will perform the modification (adding columns, etc...)
I deployed a new feature to Engine Yard that had migrations. Of course I passed the migration flag and it worked successfully. But then I decided to take the feature out.
Note: These migrations removed some columns
I then rolled back on github and deployed again, but now I'm getting a postgres error that a column doesn't exist (this is a column removed in the migration from before)
How do you rollback migrations on Engine Yard?
TMP,
While there is a rollback command built into the engineyard gem, it would be better to just deploy with a new migration that effectively adds the columns back in or update the code to not use the missing columns.
Evan
I've discovered that when you ssh into your engineyard app you can go to the current deploy's directory and run bundle exec rake ... thus you can run probably run bundle exec rake db:rollback
I wrote a Rails app locally and have maybe 10-15 migrations written. This all works fine locally.
When I wanted to deploy on heroku, I ran into a problem because they are using a earlier version of PostGreSQL than what I was using locally. One of my earliest migrations is failing because of a missing DB function in one of my database views.
I found out a way to hack around the DB function issue, but now I'm stuck because I can't write a new migration that changes the view to use the hack, since the rake db:migrate will abort after it hits the original problematic view creation.
What can I do to solve this?
First of all drop your db:
heroku pg:reset
Then run your new migrations:
heroku rake db:migrate
We need constantly update our database schema in production for rails 3.1.3 app. The first db schema was created with the following rails command:
$rake RAILS_ENV=production db:schema:load
Question is: can we still use the command above to update db schema in production while safely retaining all current data?
Thanks so much.
I never used rake db:schema:load in production, but according to this answer to another question here on SO, I don't think you want to do that.
On the other hand, I have used RAILS_ENV=production rake db:migrate several times on the server with data already in the database and never experienced any problems.