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
Related
If I try to run rails server or rails console and there are uninstalled dependencies or pending migrations, I will get an error message informing me about this.
Is there any similar Rails command that can be run for doing this check, without booting server or console?
I don't know how much you'll have to gain from checking, since you can just run the actual commands and it'll tell you the same information and take pretty much the same amount of time:
alias rs='bundle && rake db:migrate && rails s'
One thing you could do is integrate the hookup gem. It basically manages this annoyance for you whenever you change branches, automatically running bundle and rake db:migrate. It also, conveniently, rolls back migrations that are not on the branch you're changing to, which can be a pain, too. It does add a bit of a performance penalty, though, especially on larger projects.
gem install hookup
cd yourproject
hookup install
For gems it's easy enough to just run:
bundle check
For db this will show you if any migrations are pending with a "down" status:
rake db:migrate:status
or in rails 5 or higher
rails db:migrate:status #rails 5+
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
How do I undo bundle exec rake db:setup?
I ran it in the wrong rails app. I ran it in the blogger when I should have ran it in the blogger_advanced app.
You can do rake db:drop
.
It will drop all tables (thats any tables created by setup, any migrations run by setup and any seeds created by setup)
You may use rake db:rollback and it'll rollback migrations one by one, but if yours apps have same named models (User for example) it'll be lost. So you need to dump this tables first and recreate them later using database administrator tool.
And also it'll broke your schema_migrations table and you'll need to refill it by hands from your migration file names.
So if there is not much useful info, it's better to use #Alexphys approach.
I am trying to view my Heroku app's schema in Terminal (Mac OS X Lion) and stumbled upon a command that does just that. In Terminal, I run heroku run more db/schema.rb but it seems to display an older schema version. I just migrated the Heroku db and I noticed that none of the new columns are listed.
I can't seem to find anything helpful in Heroku's documentation. Does anyone know a command to view the current database schema for a Heroku app?
By the way, I inherited the code for the app and for some reason all of the migration files are commented out (there are probably 40+ files) so I can't just run rake db:migrate locally to update the schema; hence, I'd like to see the Heroku app's schema directly.
Any suggestions?
You could run heroku pg:psql to fire up a Postgres console, then issue \d to see all tables, and \d tablename to see details for a particular table.
For a rails schema, try:
$ heroku run "bundle exec rake db:schema:dump && cat db/schema.rb"
You can use rateaux:
rake db:view:schema
I have a Rails app that mounts 3 engines. Each engines has their own db migrations with timestamp in the naming of the migration dating back in 2010xxxxxx-migration-name.rb. After i run bundle exec rake railties:install:migrations, all migrations are copied to my app db/migrate but the timestamp of migrations are not respected, they are all re-named to 2011xxxx-migration-name.rb. Any idea?
The migrations are automatically renamed to cause them to not conflict with the migrations in your application. They will all be grouped together in one cohesive series of migrations rather than split out through your application.
We ran into this problem today while upgrading an old rails app that uses a pre rails 3.1 engine. That engine used the old engine plugin from lazyatom.
This engines plugin brings it's own migrator class and did not copied migration files into the apps db/migrate folder.
If one now uses the rake task to install the plugin files into the app, the timestamp gets updated and rake db:migrate tries to run all old migrations again.
Easy fix:
Copy all old migrations via rsync into the db/migrate folder without using the rake task:
rsync -ruv FULL_ENGINE_PATH/db/migrate RAILS_APP_PATH/db
For all engine developers that came from pre rails 3.1 times:
We added an upgrade rake task into our engine to handle this. So our users can easily run:
rake alchemy:upgrade
I had the same issue, took way too long to figure it out:
If a previous migration's timestamp is bigger than current timestamp, new migrations will not use timestamps.
In our case, this was caused by someone who created a migration manually without using the generator