Any way to use ActiveRecord::Enum as an attribute? about store_model

[DmitryTsepelev]

Released as part of 0.4.0, let me know if you face any issues

[DmitryTsepelev]

Hi @destructobeam, thank you for the interest to the gem!

I've tried, and looks like there is no way to do it easily, because ActiveRecord::Enum does not really work outside ActiveRecord+ActiveModel classes (StoreModel::Model uses only a part of ActiveModel).

There are some more complex options of getting the behaviour you need:

1. We can define a custom type for enums and use it to perform the conversion between value and integer (but it won't generate any additional methods):

class User
  include StoreModel::Model

  attribute :status, StoreModel::Types::Enum[active: 1, inactive: 0]
end

2. Alternatively, we can mimic the functionality of the built-in enum and keep the syntax. I guess, in this case we need to generate only status? (we cannot have status! because hash cannot save itself), am I right?

[destructobeam]

Thanks for taking a look Dmitry.

I am currently just doing all this manually at the moment by storing the string values. But if you think it’s a good feature it would be pretty cool to have.

Replicating the Rails API I think would look like this:

attribute :status, :enum => [:active, :inactive], :default => 0

attribute :status, :enum => { :inactive => 1, :active => 0 }

model.status = 0
model.status
# => :active
model.active?
# => true
model.inactive?
# => false

Seems like a bit of effort there though? What do you think?

[DmitryTsepelev]

I've played with it a bit more. Unfortunately we cannot get enums from attribute, because it comes with Rails Attributes API and it won't allow me to add any new methods, only type conversion.

I'm going to do something like enum :status, values: %i[active inactive], default: :active, which will define the attribute along with methods status (=> :active), status_value (=> 0), active? (=> true), inactive (=> :false). What do you think? Will it cover your case?

[destructobeam]

Had a look through that pull request you linked and it is looking really good!

I like what you have with the spec where you don’t need the :values key so it’s defined as enum :status => [:active, :inactive], I think it’s a bit cleaner than a seperate ‘values` option, but up to you of course.

I think that creating the status_value method is a good idea also. If you make a branch or something I am happy to test when you are happy with it.

[DmitryTsepelev]

I'd like to get rid of values: too, but in this case we won't be able to set up the default using kwargs when hash values are used: enum :status, active: 0, inactive: 1, default: :active. The only way to make it work is to define options explicitly (like enum :status, { active: 0, inactive: 1 }, default: :active) but it looks more error-prone.

Rails enum does not have default option at all, they urge us to use DB default, so we cannot steal any ideas from there. The place we can steal ideas is enumerize - they have enumerize :role, in: [:user, :admin], default: :user too

[destructobeam]

I like it without kwargs to be honest, as you would usually only use the array syntax, and the hash for edge cases I would think. Then you can use kwargs for options?

[DmitryTsepelev]

I can imagine the situation when values are important (like enum :rating, in: { excellent: 100, good: 75, bad: 25, awful: 0 }). I think we could take the best from two worlds and allow to use both in/default and array/default

[destructobeam]

Oh yeah, hadn’t thought of that, I would probably relegate something like that to a decorator personally, as it isn’t really an enum concern.

But if you want to support that use case I think :in keyword is a good second best to me 👍

[DmitryTsepelev]

Okay, I think it works, could you please use the branch enums to give it a shot before I merge? As I planned, we can use enum :status, %i[active archived], default: :active, enum :status, active: 0, archived: 1 (when we need hash) or enum :rating, in: { excellent: 100, okay: 50, bad: 25, awful: 10 }, default: :okay (when we need hash + default)

[destructobeam]

Have given the branch a quick run through in my current project and it looks really good, working as expected on my end.

Thanks so much for all your work on this, really appreciate it!

[destructobeam]

One thing I have noticed, not sure if this is expected behaviour or not, is I am not getting any errors or invalid state when I set the enum to an out of range int or a random string.

[DmitryTsepelev]

Good catch! I've fixed the issue–cast was called only when the value is accessed (and not during the assignment)

[destructobeam]

Sorry, been flat out the last few days, thanks for getting this out! Will do.