Rails 7.1 - can't define enums for attributes which don't exist in table

[ejskipper]

Not sure if this is an intended change or not. Pre 7.1, I could define an attr on a model using attribute and define enum values for it, then use enum helper methods. I'm using this heavily in my current project for i18ns etc, so defining the enum values as an array and manually validating won't cover all my use cases

Since 7.1, this isn't possible.

Steps to reproduce

# frozen_string_literal: true

require "bundler/inline"

gemfile(true) do
  source "https://rubygems.org"

  git_source(:github) { |repo| "https://github.com/#{repo}.git" }

  gem "rails", github: "rails/rails", branch: "main"
  gem "sqlite3"
end

require "active_record"
require "minitest/autorun"
require "logger"

# This connection will do for database-independent bug reports.
ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:")
ActiveRecord::Base.logger = Logger.new(STDOUT)

ActiveRecord::Schema.define do
  create_table :posts, force: true do |t|
  end
end

class Post < ActiveRecord::Base
  attribute :topic
  enum topic: %i[sports politics entertainment]
end

class BugTest < Minitest::Test
  def test_association_stuff
    post = Post.create!
    post.assign_attributes(topic: :sports)

    assert_equal true, post.sports?
  end
end# frozen_string_literal: true

Expected behavior

Post should instantiate correctly and can use enum helper methods

Actual behavior

Error thrown

RuntimeError: Unknown enum attribute 'topic' for Post

System configuration

Rails version: 7.1.1

Ruby version: ruby 3.1.2p20

[zzak]

Thanks for your report!

I've bisected this down to 6c5fab0 which was introduced in #45734.

It looks like intended behavior, but it's unclear to me why exactly this was changed. /cc @fatkodima

[fatkodima]

Yes, that was intentional. See related issue #45668 for the discussion of the problem.

cc @byroot

[ejskipper]

Thanks for the response. I'm still a bit unclear on the rationale behind this change; looking at the reported behaviour in #45668 , it seems to me that we have the same behaviour with other types, not just enums, so not sure where the difference is.
Eg if the column is a simple integer and we define attribute :wrong_attributee on Post model, we still will not throw on new_post = Post.create!(wrong_attributee: 2) # column is not in the schema cache, so why no error? and the Post will not be created with wrong_attributee = 2, just like in the code reported re: enum. (Happy to post a full test example if useful)

Either way though, I guess it boils down to the statement

While it is possible to have attributes without the columns (defined with the attribute method), the enum (which is also defined by attribute) should always have a corresponding column.

Perhaps we just need some documentation/explanation of this?

[jkwuc89]

I also have a project that is being significantly impacted by this. Is there a "simple/straightforward" way to fix the offending enum definitions in the models? Currently, this is preventing me from upgrading to Rails 7.1.

[byroot]

Is there a "simple/straightforward" way to fix the offending enum definitions in the models?

It's not quite clear to me what you are asking. Invalid enums raise an error on boot, you should be able to catch them by running your test suite.

Or are you asking for something else?

[jkwuc89]

In several of my project's models, we define enum's whose values are used to populate a character varying column (we are using Postgres). An example enum is below:

    enum order_by_types: {
      email: 'email',
      fax: 'fax',
      phone: 'phone',
      website: 'website'
    }

Before Rails 7.1, referencing and using enum's like order_by_types above did not raise any errors. With Rails 7.1, tests are now failing with errors like the following:

     RuntimeError:
       Unknown enum attribute 'order_by_types' for Deals::Judgment

What I am looking for is some guidance on how best to fix this. It appears that we can no longer define enum's inside models without a corresponding database table column.

[byroot]

I don't follow. You say:

we define enum's whose values are used to populate a character varying column

And then:

we can no longer define enum's inside models without a corresponding database table column.

So first you say the enum is backed by a column, then you say it's not. It's really confusing.

[jkwuc89]

My apologies...it looks like it may be a simple case of order_by_types not matching the order_by_type column name. I am going to check my enum's and correct the name mismatches to see if that fixes things.

[byroot]

it looks like it may be a simple case of order_by_types not matching the order_by_type column name

If that's so, then that's exactly why we made this change. To catch these typos.

[jkwuc89]

Changing the enum name to match the corresponding column name is fixing things for me. Again...my apologies for the confusion/noise in this thread.

[ejskipper]

I think as jkwuc says, that wasn't actually related to my original question.

It seems like the my issue (enums for attributes which are not backed by a column) is now explicitly unsupported, and the way forwards is to rewrite the enums into arrays and explicitly validate inclusion in those values, and manually feed in the enum options and i18ns to the inputs on forms, etc. If anyone has elegant ways of doing this then would be interested to hear!

I guess the documentation for enum does say pretty clearly that it should be backed by a DB column, so hopefully that's sufficient for others going forwards to know that this use case isn't supported.

Declare an enum attribute where the values map to integers in the database, but can be queried by name

[byroot]

my issue (enums for attributes which are not backed by a column) is now explicitly unsupported

If you have time, I'd be curious to hear what was your use case and how it worked. It's unlikely we'll revert this change (even more so now that @jkwuc89's comments showed it caught some real world issues), but perhaps there's some other change of feature for your use case.