Consequences of overriding update_attribute to force validation?

Rails
1

I know the debate of whether this should validate has been rehashed
many times. My question is, what are the consequences of overriding
this method to force validation? Will this break fundamental things?
Will it break plugins? Is there a reason not to have a strict
validation option?

In my code I will never use this as I consider it a terribly broken
method, but some gems use it and in one case I was just burned.

I do not want invalid objects in my database under any circumstances,
since the rest of my code rationally depends on validations - e.g. I
don’t check for null associations when the association is validated to
be there.

For the uninitiated, update_attribute:

  1. Does not ever validate the object, causing a massive hole in your
    validation schemes. For instance, if a validation depends on anything
    you update with update_attribute, that validation will not work.

  2. Updates ALL fields if the object has been modified. @user.email =
    ‘invalidemail’; @user.update_attribute(:state, ‘registered’); will
    always put an invalid email in your database.

  3. Saves the object regardless of whether it’s been persisted. E.g.
    User.new.update_attribute(:state, ‘registered’) will always save a new
    user object, even if you have all kinds of validations to guarantee
    associations and properties are present. This is likely to seriously
    break your application if it happens.

2

On Saturday, May 21, 2011 12:54:32 PM UTC-6, Alex N wrote:

I know the debate of whether this should validate has been rehashed
many times. My question is, what are the consequences of overriding
this method to force validation? Will this break fundamental things?
Will it break plugins? Is there a reason not to have a strict
validation option?

In my code I will never use this as I consider it a terribly broken
method, but some gems use it and in one case I was just burned.

I can’t comment on whether overriding #update_attribute would “break
fundamental things” or not. However…

I would consider the gem in your project that uses it broken and raise
the
use of this method within said gem with the gem author. For a gem to
blindly
use it does seem unsafe unless such behavior is well-known and
documented.
If, for performance reasons, some gem wants to do unvalidated writes to
the
database, that’s find if the gem provides copious
warning/documentation
and/or its own dual-API that corresponds to the rails
validated/unvalidated
DB access.

If I were you and I really wanted to monkey-patch #update_attribute to
validate, I’d just create a test/feature branch of my project and try it
out. If it doesn’t break anything (and performance is fine) then cool.
Otherwise you then have the answer to your question.

Anyhow, that’s just my $0.02