-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thoughts on ActiveRecord enum #144
Comments
tejasbubane
added a commit
to tejasbubane/rails-style-guide
that referenced
this issue
Jul 8, 2019
tejasbubane
added a commit
to tejasbubane/rails-style-guide
that referenced
this issue
Jul 8, 2019
tejasbubane
added a commit
to tejasbubane/rails-style-guide
that referenced
this issue
Jul 8, 2019
goldapple911
added a commit
to goldapple911/rails-style-guide
that referenced
this issue
Aug 15, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
tldr; Specifying the stored value rather than the ordinal is a much safer approach and I'd like to see it added to this style guide.
I really like the idea of ActiveRecord enums, but feel relying on the ordinal value is quite dangerous.
Reordering or removing an enum value would be catastrophic to a system with a significant amount of data. It's also very unlikely it would be caught by a unit or functional tests which typically start with a clean db state.
I don't want to use the hyperbolic example of someone alphabetizing a list to suddenly reverse permissions for the system:
enum status: [ :enabled, :disabled ]
->enum status: [ :disabled, :enabled ] #FTFY
It's more likely it would result in adding mangos to a system and forcing strawberry lovers to have their favorite fruit misrepresented:
enum favorite_fruit: [ :apples, :bananas, :strawberries ]
to
Regardless it's just to easy to want to add mangos to this list alphabetically. Some might even argue it's bad form to have it out of order. Consider an unordered list of 50'ish values.
For a few more characters, the explicit nature of specifying the enum's value forces the developer to acknowledge they are actually mapped to an underlying value.
While you still have the option to screw up the value (it even accepts duplicate values), I feel like the chances of an innocent style based reordering or requirement based refactoring are more easily understood at face value.
I'd even like to see a rule for Rubocop to enforce this in my projects, but it could just be like, you know, my opinion man...
Thoughts?
The text was updated successfully, but these errors were encountered: