ActiveRecord::NoEnvironmentInSchemaError
Asked Answered
M

5

32

I'm trying to perform database related operations on my newly upgraded app(Rails 5) and I'm unable to perform destructive database commands locally.
rails db:reset or rails db:drop .

The trace results with the following data,

rails db:drop --trace
** Invoke db:drop (first_time)
** Invoke db:load_config (first_time)
** Execute db:load_config
** Invoke db:check_protected_environments (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config
** Execute db:check_protected_environments

rails aborted!
ActiveRecord::NoEnvironmentInSchemaError: 

Environment data not found in the schema. To resolve this issue, run: 

    bin/rails db:environment:set RAILS_ENV=development

What I've tried so far are,

  1. Setting bin/rails db:environment:set RAILS_ENV=development, doesn't change anything still the error occurs.
  2. Setting Environment variable manually to development.

None of these helped. I'm Looking for a fix or workaround.

Misbecome answered 28/8, 2017 at 18:37 Comment(2)
Maybe this is relevant: github.com/rails/rails/issues/23279#issuecomment-267087520 – Senghor
Just in case this was your issue, We were running into this on Rails 5.0.x with MySQL 8.x. We had to upgrade Rails to 2.x in order for this to work. – Sweptback
U
32

Two Fixes to ActiveRecord::NoEnvironmentInSchemaError

The other answers here describe the problem very well, but lack proper solutions. Hoping this answer helps someone experiencing this issue.

Why this error is happening

This incorrect error message is a result of this pull request designed to prevent destructive actions on production databases. As u/pixelearth correctly points out, Rails 4.2 defines the 'key' field in the ar_internal_metadata table to be an integer, and Rails 5+ (including Rails 6) expects this to be a string with the value, environment. When Rails 5 and Rails 6 run this safety check, they incorrectly raise an ActiveRecord::NoEnvironmentInSchemaError as the code is incompatible with the Rails 4 schema format.

Fix #1: Override the safety check in Rails 5+

**Please remember, the safety check was implemented as a result of so many users dropping their production databases by accident. As the question describes, the operations are destructive.

From the terminal:

rails db:drop RAILS_ENV=development DISABLE_DATABASE_ENVIRONMENT_CHECK=1
# and/or
rails db:drop RAILS_ENV=test DISABLE_DATABASE_ENVIRONMENT_CHECK=1

As noted here, the DISABLE_DATABASE_ENVIRONMENT_CHECK=1 flag disables the environment check. After, you can run a rake db:create RAILS_ENV=development, for example, to recreate your database with the correct schema in the ar_internals_metadata table.

Fix #2: Revert to Rails 4, drop database, go back to Rails 5+ and recreate

From the terminal:

git log
# grab the commit hash from before the upgrade to Rails 5+

git checkout **hash_from_rails_4**
rake db:drop RAILS_ENV=development
rake db:drop RAILS_ENV=test

git checkout master

# now things should work
rails db:migrate

Again, please ensure you are not pointing at a production database when overriding this functionality. Alternatively, it would be possible to directly modify the schema of this table. If you're experiencing this error in production, you may need to take this approach.

Ultimo answered 20/1, 2020 at 16:2 Comment(1)
For Fix #2 you don't need to revert to Rails 4 to drop the database; instead just drop the database yourself and try again (this worked for me); i.e.: psql, then \l to find the name of my test database, then I dropped it with drop database my_project_test;, then exited. Then I was good to go πŸ‘Œ thanks for helping me find this solution! – Officious
Z
14

This happened because, for some reason, your table ar_internal_metadata got deleted or changed. If you cannot drop the database via the command line, you need to do it via your DBMS or database client. Then, just run rails db:create db:migrate to create and run the migrations.

Zelikow answered 4/4, 2018 at 13:8 Comment(0)
H
5

For posterity, my issue was that this schema was generated by a rails 4 app and the current app using it is rails 5. With rails 5 the structure of the ar_internal_metadata table has changed slightly. The key field needs to be a string and contain the word 'environment', not an integer. This error only goes away when this is changed.

It should look like this in Rails 5

enter image description here

ie, change the type of ar_internatl_metadata #key to string...

My situation is a bit uncommon involving a rails 4 app and a rails 5 app sharing the same db. When I need to "update", I have a task:

  puts "Modifying Rails 4 schema to fit Rails 5 schema"
  file_name = "./db/schema.rb"
  rails_4_ar_internal_metadata = 'create_table "ar_internal_metadata", primary_key: "key", force: :cascade do |t|'
  rails_5_ar_internal_metadata = 'create_table "ar_internal_metadata", primary_key: "key", id: :string, force: :cascade do |t|'
  new_schema = File.read(file_name).gsub(rails_4_ar_internal_metadata, rails_5_ar_internal_metadata)
  File.write(file_name, new_schema)
Hoop answered 26/5, 2019 at 0:22 Comment(2)
So what are the steps in code you used to rectify the problem? – Nutmeg
so you used a GUI to modify this? do you know how to do it in pure code? – Nutmeg
H
3

Console rails

bin/rails db:environment:set RAILS_ENV=development
Hest answered 16/12, 2020 at 4:35 Comment(0)
A
1

I had

bundle exec rake db:drop
rake aborted!
ActiveRecord::NoEnvironmentInSchemaError: 

Environment data not found in the schema. To resolve this issue, run: 

        rails db:environment:set RAILS_ENV=development

And, indeed, simply running rails db:environment:set RAILS_ENV=development made the problem go away.

Why did this happen?

It happened because I tried to drop the database and create it / migrate it, however, I had a syntax error in the migration (datatype and column name in the wrong places). Check your migration file for any silly errors

Specifically I had

t.submitted :boolean, default: false

instead of

t.boolean :submitted, default: false
Athlete answered 13/2, 2021 at 11:7 Comment(0)

© 2022 - 2024 β€” McMap. All rights reserved.