Skip to content
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

Closed
jhirn opened this issue Jun 3, 2015 · 0 comments · Fixed by #255
Closed

Thoughts on ActiveRecord enum #144

jhirn opened this issue Jun 3, 2015 · 0 comments · Fixed by #255

Comments

@jhirn
Copy link

jhirn commented Jun 3, 2015

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

enum favorite_fruit: [ 
    :apples, 
    :bananas, 
    :mangos, 
    :strawberries 
] #Take that red fruit eaters!

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.

enum favorite_fruit: { 
   apples: 1, 
   bananas: 2, 
   mangos: 4,
   strawberries: 3
} #Strawberry lovers are people too!

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?

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
@koic koic closed this as completed in #255 Jul 17, 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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant