[ActiveRecord] Enum defined methods does not follow naming convention about rails HOT 5 CLOSED

I did not get what the problem is?

Rails generates both methods ("pretty" and "not pretty") on purpose -

from rails.

I did not get what the problem is?

Rails generates both methods ("pretty" and "not pretty") on purpose -

rails/activerecord/lib/active_record/enum.rb

Lines 279 to 294 in 284baa1

	pairs.each do |label, value|
	enum_values[label] = value
	label = label.to_s
	value_method_name = "#{prefix}#{label}#{suffix}"
	value_method_names << value_method_name
	define_enum_methods(name, value_method_name, value, scopes, instance_methods)
	method_friendly_label = label.gsub(/[\W&&[:ascii:]]+/, "_")
	value_method_alias = "#{prefix}#{method_friendly_label}#{suffix}"
	if value_method_alias != value_method_name && !value_method_names.include?(value_method_alias)
	value_method_names << value_method_alias
	define_enum_methods(name, value_method_alias, value, scopes, instance_methods)
	end
	end

@fatkodima Upon reviewing the command output below, it's evident that the method name US West (Oregon)! contains spaces and brackets, which deviates from standard programming naming conventions. I've noticed this discrepancy, and it seems there might be an issue with adhering to the naming convention for methods.

Additionally, we recently integrated an enum into our application with the following values. However, we discovered that calling the method for the corresponding keys is not possible without utilizing 'send', primarily due to the naming convention.

Could you kindly clarify if Rails intentionally maintains this naming convention? and Why?

Additionally, @fatkodima, it's worth noting that this change was introduced after the merge of #40992. In previous versions before this merge, we only had the pretty method.

[1] pry(#<BugTest>)> john.methods.select { |method| method.to_s.include? "US"}
=> [:"US West (Oregon)!", :US_West_Oregon_?, :US_West_Oregon_!, :"US West (Oregon)?"]

from rails.

As you can see from the removed tests in the PR you opened, this is intentional. It keeps original enum key names to be able to use exact key names (via send, for example). And a mangled name to be able to little easier use it in the code, like for:
User.enum foo: {"foo bar" => 1} you can call User.foo_bar.

For enums with keys like in the description for this issue, it is a pain to use either of the approaches. But this is how it is done and removing this behavior is at least breaking, without saying that it is not needed.

from rails.

As you can see from the removed tests in the PR you opened, this is intentional. It keeps original enum key names to be able to use exact key names (via send, for example). And a mangled name to be able to little easier use it in the code, like for: User.enum foo: {"foo bar" => 1} you can call User.foo_bar.

For enums with keys like in the description for this issue, it is a pain to use either of the approaches. But this is how it is done and removing this behavior is at least breaking, without saying that it is not needed.

@fatkodima, I suggest that instead of using either approach, we consider restricting the definition of enum keys to follow a convention friendly to programming methods.

And if you look at pretty method that are generated by Rails they are also not as per the naming convention.

For example: US_West_Oregon_?

1. Method name starts with the capital letter.
2. Method name ends with _ because actual key name ends with ")". These pretty methods are also not name friendly.

from rails.

Like @fatkodima the current behavior is intentional. I'd actually suggest no use enums like this instead, but if you want to, you will get the current behavior of having two methods to the same enum key.

from rails.