ActiveRecord dynamic attribute methods

in a project we are enforcing permissions by wrapping active record
objects and arrays of ar objects in a proxy class. this proxy class is
a BasicObject that uses #method_missing to send methods to a target
(the ar object) i believe this is how :has_many association/reflection
works (at least in 2.x).

i wanted to benchmark this technique against simply extending ar
objects on the fly with a permissions module. now i realize extending
objects create entirely new singleton classes but i just wanted to
test this method out.

i thought i could simply over-write the #read_attribute and
#write_attribute methods and enforce permissions that way but it seems
not all dynamic attribute methods utilize these methods. all attribute
setter methods look like they are routed through #write_attribute, but
not all getter methods are routed through #read_attribute - as far as
i can tell only datetime getters are routed through #read_attribute.
all other getter methods touch the @attributes instance variable

does anyone know why the dynamic getter attribute methods behave this
way? wouldn’t it be prudent to have one end-all-be-all method that all
read attribute methods go through? (excluding before type casting

after looking deeper in ActiveModel i found that all dynamically
generated attribute methods are included in a dynamic anonymous
module. it can be accessed from an active record class
via .generated_attribute_methods (User.generated_attribute_methods)

i was eventually able to alias all generated methods and set up a
permission chain upon object extension - this method works but seems
very HEAVY. would be nicer if all attribute manipulation went through
#read_attribute and #write_attribute.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs