update_attribute (singular) method to behave more intuitively and consistently like
update_attributes (plural). ActiveRecord's built-in
update_attribute (singular) will skip validation checks
and save the record regardless, unlike
update_attributes (plural), which will not.
Add the following to your Rails 3 Gemfile:
Then add the following to an
update_attribute_with_validations.rb file in your initializers folder (or to your environment.rb):
- We should be using attr_accessible to white list attributes that can be safely mass assigned from a web form.
update_attributes(plural), therefore, cannot be used within the application to quickly update other attributes that are not, and should not, be updateable via a web form.
- We are then left with several alternatives.
@object.attribute=value; @object.savewhich is not beautiful code.
@object.update_attribute(:attribute,value)and hope we never inadvertently create an invalid object in the database.
- define a new ActiveRecord method that intuitively does what we expect. But what to call it? How about
update_attribu... oh, shucks!
- "Fix" the built-in
update_attributemethod so that safe updates are easy, and unsafe updates are hard(er).
- This gem takes the last approach.
Admittedly, it is occasionally necessary to save some value regardless of whether or not the resultant object passes validations. Or, you just know that it's safe and in your particular case there's a significant performance boost to be gained by skipping unnecessary validations.
update_attribute_without_validations(:attribute,value) provides the built-in functionality, and also comes
with the free bonus of self documenting code.
It is the author's opinion, however, that this is an edge case and should not dictate the default behavior.
The built-in behavior of
update_attribute has been debated at length.
The winning argument seems to primarily be that many people have code that relies on the existing behavior and do not
want to update that code to adjust for new behavior. The author of this gem harbors no delusions of ever changing the
core team's mind, but is unmoved by that rationale. New versions of libraries always require dependent code to be updated
if it is to be expected to work with the new way of doing things. The referenced discussion, however, was over three
years ago, Rails 3 has since been released, and the behavior in question remains. End of discussion.