Some attributes not updated when validation fails?

Rails
1

I have what I think is a simply question.

If I call update_attributes(params[:whatever]) to update my attributes
for object :whatever, does the attribute updating stop as soon as any
validation rule fails?

Assume 5 attributes, a-e. If a validates_xxx for “c” fails, does
update_attributes return right away?

The reason I’m asking is that I have some attributes that I want to
update even if validation for other attributes fails.

Do I need to take complete control of my attribute updating in this
case?

I see that “update_attribute” (not plural) seems to address this.

Do I need to update my attributes one-by-one using update_attribute on
params.each?

If so, what is the point of update_attributes then?

Thanks,
Wes

2

Wes G. wrote:

update even if validation for other attributes fails.

Do I need to take complete control of my attribute updating in this
case?

I see that “update_attribute” (not plural) seems to address this.

Do I need to update my attributes one-by-one using update_attribute on
params.each?

No, update_attributes will update all non-protected attributes in
its argument hash before validation is performed. Is this not
what you’re seeing?

–
We develop, watch us RoR, in numbers too big to ignore.

3

No, update_attributes will update all non-protected attributes in
its argument hash before validation is performed. Is this not
what you’re seeing?

Mark,

I am seeing the expected behavior on one page but not another. I have
convinced myself that update_attributes works so I just need to figure
out what other problem I have.

One thing to note is that I combined update_attributes and save!
together into one function that I named update_attributes! (defined in
environment.rb) - seen below.

class ActiveRecord::Base
def update_attributes!(attributes)
self.attributes = attributes
save!
end
end

This could be it, huh? I’m never actually calling update_attributes
here. I will test it.

Thanks for replying.

Wes

4

On the other hand, I’m using this exact same scheme in two places and
things work as I expect them to in one but not the other.

I’ll figure it out and post the solution when I have it.

Thanks,
Wes

5

Wes G. wrote:

This could be it, huh? I’m never actually calling update_attributes
here. I will test it.

It’s the same way core currently does update_attributes, so it
should be fine, and would be a useful core addition.

Are you sure that the attributes you’re updating aren’t protected
(including id and STI-type), and that there are no lurking
custom attribute setter methods.

–
We develop, watch us RoR, in numbers too big to ignore.

6

Mark,

Thanks for the suggestion that my update_attributes! method would be
useful overall. I think so too.

As I suspected, my problem was my own. I had two forms that did the
exact same thing, which was:

Given a checkbox, if the checkbox was checked, I wanted to force a text
field’s attribute value to be 0. So my attribute setters would have to
handle ensuring that text box attribute was 0 if checkbox attribute was
‘1’.

My ultimate problem was that the naming of my fields in the two forms
was different so that in one form, the checkbox was updated before the
text field because those attributes were alphabetically in that order,
and in the other, the opposite update order was occurring.

Because my setter for the text field wasn’t smart enough to check the
state of the checkbox, in one form, the checkbox would force the
attribute value of the text field to 0, and then the text field would
happily update itself to be the value from the form. This led to my
desperate question :).

In fact, I should probably force the text field value on the client as
soon as the checkbox is checked using Javascript, and then my setters
don’t have to be so smart.

Wes