This blog is part of our Rails 5 series.

Sometimes while debugging production issue mistakenly developers execute commands like RAILS_ENV=production rake db:schema:load. This wipes out data in production.

Users of heroku download all the config variables to local machine to debug production problem and sometimes developers mistakenly execute commands which wipes out production data. This has happened enough number of times to heroku users that Richard Schneeman of heroku decided to do something about this issue.

Rails 5 prevents destructive action on production database

Rails 5 has added a new table ar_internal_metadata to store environment version which is used at the time of migrating the database.

When the first time rake db:migrate is executed then new table stores the value production. Now whenever we load database schema or database structure by running rake db:schema:load or rake db:structure:load Rails will check if Rails environment is “production” or not. If not then Rails will raise an exception and thus preventing the data wipeout.

To skip this environment check we can manually pass DISABLE_DATABASE_ENVIRONMENT_CHECK=1 as an argument with load schema/structure db command.

Here is an example of running rake db:schema:load when development db is pointing to production database.

$ rake db:schema:load

rake aborted!
ActiveRecord::ProtectedEnvironmentError: You are attempting to run a destructive action against your 'production' database.
If you are sure you want to continue, run the same command with the environment variable:
DISABLE_DATABASE_ENVIRONMENT_CHECK=1

As we can see Rails prevented data wipeout in production.

This is one of those features which hopefully you won’t notice. However if you happen to do something destructive to your production database then this feature will come in handy.