{"id":205,"date":"2009-06-25T16:05:00","date_gmt":"2009-06-26T00:05:00","guid":{"rendered":"http:\/\/onehub.com\/blog\/posts\/decorating-activerecord-accessor-methods"},"modified":"2013-07-26T14:50:05","modified_gmt":"2013-07-26T21:50:05","slug":"decorating-activerecord-accessor-methods","status":"publish","type":"post","link":"https:\/\/www.onehub.com\/blog\/2009\/06\/25\/decorating-activerecord-accessor-methods\/","title":{"rendered":"Decorating ActiveRecord Accessor Methods"},"content":{"rendered":"

Recently, I was faced with a quandary. I needed to impart some of our ActiveRecord accessor methods with special functionality, but I also needed to maintain the default behavior for those fields. This was done to support a new input type which we added to the venerable CalendarDateSelect plugin<\/a> which allows a user to enter a date, time, and meridian, all in separate fields.<\/p>\n

\"calendar_date_select_fields\"<\/a><\/p>\n

Though I could parse each of the fields in the controller and pass the resulting time to the model, this is messy, error-prone, and unnecessary.<\/p>\n

What I really want to be able to do is something like this:<\/p>\n

\r\n>> CalendarEvent.new(\r\n:start_time => {:date => '6\/23\/2009', :time => '12:30', :meridian => 'pm'})\r\n=> #<CalendarEvent start_time: \"2009-06-23 19:30:00\">\r\n<\/pre>\n
My first thought was to simply override the accessor methods like so:<\/p>\n
\r\nCalendarEvent < ActiveRecord::Base\r\n...\r\ndef start_time=(new_time)\r\nself[:start_time] = parse_time_from_hash(new_time)\r\nend\r\nend\r\n<\/pre>\n
However, as I alluded to before, there’s a problem with this approach. Rails already does some magic behind the scenes to ensure that time values stored to your ActiveRecord objects are automatically cast to and from UTC. The code above will completely overwrite these default accessors, and time zone casting will cease to function for those fields. What I really want to do is decorate<\/a> these accessor methods, so that I can add to the existing functionality without completely circumventing it.<\/p>\n
One way we might think about accomplishing this would be to redefine our accessor method and add behavior to it using alias_method_chain<\/a>.<\/p>\n
\r\ndef start_time_with_hash_parsing=(new_time)\r\nnew_time = parse_time_from_hash(new_time)\r\nstart_time_without_hash_parsing = new_time\r\nend\r\nalias_method_chain :start_time=, :hash_parsing\r\n<\/pre>\n
Try that, though, and you’ll get this fun little error<\/p>\n
\r\n`alias_method':NameError: undefined method `start_time=' for class `CalendarEvent'\r\n<\/pre>\n
It doesn’t work because there is no original start_time=<\/code> method to alias; ActiveRecord creates those methods only when the class is loaded, because it has to read the columns from the database at runtime. So, how do you decorate methods which haven’t even been created yet? Well, it turns out you have to decorate ActiveRecord::Base.define_attribute_methods<\/code>, which is responsible for creating accessor methods for each model.<\/p>\n
There are a couple of ways you can go about doing this, depending on your goals. I wanted to be able to use these enhanced date\/time inputs with any model in our application and trigger it from an initializer, so my approach uses alias_method_chain<\/code> to modify ActiveRecord::Base<\/code> directly.<\/p>\n
\r\nmodule TimeAttributeExtensions\r\nmodule ClassMethods\r\n\r\ndef define_attribute_methods_with_time_parsing\r\nif define_attribute_methods_without_time_parsing\r\n\r\ncolumns_hash.each do |name, column|\r\nif [:datetime, :timestamp].include?(column.type)\r\nunless method_defined?(:\"#{name}_without_time_parsing=\")\r\n\r\ndefine_method(\"#{name}_with_time_parsing=\") do |time|\r\nsend(:\"#{name}_without_time_parsing=\", parse_time_from_hash(time))\r\nend\r\n\r\nalias_method_chain :\"#{name}=\", :time_parsing\r\nend\r\nend\r\nend\r\n\r\nreturn true\r\nend\r\nend\r\nend\r\n\r\nmodule InstanceMethods\r\ndef parse_time_from_hash(time)\r\n# Do time parsing here\r\nend\r\nend\r\n\r\ndef self.included(receiver)\r\nreceiver.send(:include, InstanceMethods)\r\nreceiver.extend ClassMethods\r\n\r\nunless receiver.respond_to?(:define_attribute_methods_without_time_parsing)\r\nclass << receiver\r\nalias_method_chain :define_attribute_methods, :time_parsing\r\nend\r\nend\r\nend\r\nend\r\n<\/pre>\n
Ok, so what exactly does that code do? First, we call the original version of define_attribute_methods<\/code>. If that returns true, then we know that the attribute accessor methods have been generated. We loop over each column in the model, checking to see whether it stores either a datetime or a timestamp. If so, this is an accessor we’re interested in decorating. We do a quick check to make sure we haven’t already decorated the accessor (which can bite us in development mode), then we redefine the accessor with<\/em> time parsing, and use the magic of alias_method_chain<\/code> to alias our original method but still maintain a reference to it.<\/p>\n
At the bottom, we use the Module#included<\/code> callback to add the methods contained in our module, and we once again use alias_method_chain<\/code> to redefine our version of define_attribute_methods<\/code>.<\/p>\n
Then, in the initializer, you would write something like<\/p>\n
\r\nActiveRecord::Base.send(:include, TimeAttributeExtensions)\r\n<\/pre>\n
At this point, any time-based field in any of your models will be able to accept a hash as a value, and properly parse it.<\/p>\n
This works well, but one thing I don’t like about this solution is its rampant use of alias_method_chain<\/code>. There has been some debate<\/a> in the Rails community over its validity as a design choice, though there really are no other options if you need to modify all subclasses of ActiveRecord::Base<\/code> (as you would to support a plugin like CalendarDateSelect).<\/p>\n
Another Approach<\/h3>\n
If modifying every subclass isn’t a design requirement, you can clean up the code significantly:<\/p>\n
\r\nmodule TimeAttributeExtensions\r\nmodule ClassMethods\r\n\r\ndef define_attribute_methods\r\nif super\r\ncolumns_hash.each do |name, column|\r\nif [:datetime, :timestamp].include?(column.type)\r\ndefine_method(\"#{name}=\") do |time|\r\nsuper parse_time_from_hash(time)\r\nend\r\nend\r\nend\r\n\r\nreturn true\r\nend\r\nend\r\nend\r\n\r\nmodule InstanceMethods\r\ndef parse_time_from_hash(time)\r\n# Do time parsing here\r\nend\r\nend\r\n\r\ndef self.included(receiver)\r\nreceiver.send(:include, InstanceMethods)\r\nreceiver.extend ClassMethods\r\nend\r\nend\r\n<\/pre>\n
Notice here we’re just defining define_attribute_methods<\/code> and calling super<\/code> when we want access to the previous implementation. The same goes for decorating the actual accessor methods.<\/p>\n
The downside of this approach is that you have to explicitly include the module in your ActiveRecord models:<\/p>\n
\r\nCalendarEvent < ActiveRecord::Base\r\ninclude TimeAttributeExtensions\r\n...\r\n<\/pre>\n
As with any decision, the approach you take will depend on your requirements, and tradeoffs you’re willing to make between explicitness and ease of use.<\/p>\n","protected":false},"excerpt":{"rendered":"
Recently, I was faced with a quandary. I needed to impart some of our ActiveRecord accessor methods with special functionality, but I also needed to maintain the default behavior for those fields. This was done to support a new input […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_themeisle_gutenberg_block_has_review":false},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/posts\/205"}],"collection":[{"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/comments?post=205"}],"version-history":[{"count":0,"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/posts\/205\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/media?parent=205"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/categories?post=205"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.onehub.com\/blog\/wp-json\/wp\/v2\/tags?post=205"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}