make changed_attributes work with new enum feature

[barelyknown]

Changed per the discussion in PR #13267.

[chancancode]

Can you add this back?

[chancancode]

I'm not sure if doing this from the read_attribute level is the right approach. (And since this is enum-specific, if we were to do this, we should probably be overriding read_attribute and call super.) Masking access to the raw DB value for this purpose seems like a bad idea (and the fact that write_attribute doesn't work the same would be quite odd as well). I view Enums as a higher-level connivence feature that builds on top of the lower level AR primitives, so we should probably deal with this from a higher level.

(Sorry - I haven't looked into this enough to suggest a good alternative approach yet, just adding my concerns for now)

[chancancode]

cc @senny @dhh

[barelyknown]

I agree that it's better to override read_attribute and call super. I made that adjustment and the code is much better. While I'm not 100% confident that changing read_attribute is the right strategy, it seemed like the best place as I read through the code. The fact that the enum is stored as an integer is a performance issue in my opinion, and I couldn't think of why the user would ever want to deal with the integer when using an ActiveRecord instance. So, self[enum_attribute_name] should also return the string version not the integer I think.

[barelyknown]

What does everyone think of this? It'd great to
have this in 4.1.

[egilburg]

why can't just use self::ENUMS here and in other places using klass?

[barelyknown]

I cargo culted from the enum method right below. I wanted to follow the convention that the rest of the module was using.

[dhh]

Kill newlines after block indentions here and anywhere else as well.

[dhh]

Would this impact the solution we had to dealing with form fields and enums?

[chancancode]

Let's leave this (and the related code) out of this PR, I'll tackle that in #13450