(Repurposing my answer to this stackoverflow question as a blog post)
If you are using Rails 4.x on Heroku and you have your schema format set to sql (which you probably should), you will see this error when running
heroku run rake db:migrate
1 2 3 4
This is an interesting bug that, as it turns out, can be ignored.
ActiveRecord will only run the task
db:structure:dump if you are using ‘sql’ as
active_record.schema_format. And that rake task (
fail on Heroku because the executable
pg_dump is (unsurprisingly) not in the
binary path. Interestingly enough, Heroku states that
db:schema:dump is not
supported but if you set the schema format to ruby, it works fine. Of course,
you would end up with a
schema.rb file on one-off dyno that will not exist
shortly after the rake task finished running.
In Rails 3, the dump task would only raise an error is the exit code of the
command was 1. On unix based systems if a command is not found, the exit code
is 127. So even if the
pg_dump command fails on Rails 3 (which it does), it
won’t raise an error and it won’t halt the rake task. So anyone using a sql
schema format with Rails 3 wouldn’t have this issue because it would fail
silently. The code was refactored in Rails 4 to properly raise an error if the dump failed.
This means that
db:migrate will raise an error on Heroku.
However, even though it errors with rake aborted the DDL from the migration is actually executed and committed.
Here are some possible solutions (if the error really bothers you):
- Ignore the error as the migrations are actually running.
- Since you don’t care about the structure dump on production, set the schema_format to ruby. In config/environments/production.rb:
- If for some reason you don’t want to change the config file: add a rake task with the following to suppress the error:
1 2 3