Update_attributes not working in self.up migration

i have a migration script that looks like this:

def self.up
rename_column :books, :finalizing, :progress_step
change_column :books, :progress_step, :integer, :length=>2
Book.find(:all).each do |book|
book.update_attributes(:progress_step=>3) if book.published_at
book.update_attributes(:progress_step=>1) if !book.published_at
book.update_attributes(:views=>0) if !book.views
end
puts “rebuilding ferret index”
Rake::Task[“ferret:rebuild_index”].invoke
end

When I checked the database fields, it turns out that progress step is
still NULL.

Do you guys have any idea why this could be?

Do I need to do book.reload or something?

On May 16, 2007, at 3:01 AM, Aryk G. wrote:

puts “rebuilding ferret index”
Rake::Task[“ferret:rebuild_index”].invoke
end

When I checked the database fields, it turns out that progress step is
still NULL.

Do you guys have any idea why this could be?

Do I need to do book.reload or something?

Look at the difference in what “update_attributes” (with an “s”) does
compared to “update_attribute”. You want the singular form for what
you’re doing. The plural version replaces the entire attributes
property of the object.

-Rob

Rob B. http://agileconsultingllc.com
[email protected]

On 5/16/07, Aryk G. [email protected] wrote:

end
puts “rebuilding ferret index”
Rake::Task[“ferret:rebuild_index”].invoke
end

When I checked the database fields, it turns out that progress step is
still NULL.

Do you guys have any idea why this could be?

Do I need to do book.reload or something?

You need to call

Book.reset_column_information

There’s an example of this in the API docs for
ActiveRecord::Migration. Look for “Using a model after changing its
table”

On 5/16/07, Rob B. [email protected] wrote:

Look at the difference in what “update_attributes” (with an “s”) does
compared to “update_attribute”. You want the singular form for what
you’re doing. The plural version replaces the entire attributes
property of the object.

I’m pretty sure that’s not correct. You can update only a subset of
the attributes with this method.

Yeah I was a little worried, because I like passing my updates as
hashes,

I tend to use update_attributes A LOT, even on single attribute
assignments.

It seems like that only real difference is that update_attributes saves
with validation.

Is their a huge performance decrease with using update_attributes since
it calls the attributes= EXCEPT for the fact that it runs validations of
course?

Be very careful with your answer, I might get a heart attack having to
modify all my updates. =)

Aryk

On May 16, 2007, at 11:39 AM, Bob S. wrote:

On 5/16/07, Rob B. [email protected] wrote:

Look at the difference in what “update_attributes” (with an “s”) does
compared to “update_attribute”. You want the singular form for what
you’re doing. The plural version replaces the entire attributes
property of the object.

I’m pretty sure that’s not correct. You can update only a subset of
the attributes with this method.

You’re correct, Bob. I let my old habits get the better of me and
assumed that self.attributes=attributes;save was doing a simple
writer. Silly me!

-Rob

Rob B. http://agileconsultingllc.com
[email protected]

Not quite sure what you mean by the internal updates to form and
non-form attributes.

BTW, how can an attribute in the database be protected? And what does
that exactly mean?

Mark Reginald J. wrote:

Aryk G. wrote:

Yeah I was a little worried, because I like passing my updates as
hashes,

I tend to use update_attributes A LOT, even on single attribute
assignments.

It seems like that only real difference is that update_attributes saves
with validation.

update_attributes will also not update protected attributes.

Is their a huge performance decrease with using update_attributes since
it calls the attributes= EXCEPT for the fact that it runs validations of
course?

It depends on how expensive validation is, and how important it
is to have a sanity check on the internal updates you make to
form and non-form attributes.


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

Aryk G. wrote:

Yeah I was a little worried, because I like passing my updates as
hashes,

I tend to use update_attributes A LOT, even on single attribute
assignments.

It seems like that only real difference is that update_attributes saves
with validation.

update_attributes will also not update protected attributes.

Is their a huge performance decrease with using update_attributes since
it calls the attributes= EXCEPT for the fact that it runs validations of
course?

It depends on how expensive validation is, and how important it
is to have a sanity check on the internal updates you make to
form and non-form attributes.


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

Aryk G. wrote:

Not quite sure what you mean by the internal updates to form and
non-form attributes.

Updates to attributes, both those normally used in posted client forms
and internal-only attributes, unrelated to form postings.

BTW, how can an attribute in the database be protected? And what does
that exactly mean?

See: http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001006


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

ooh woops, nevermind about the protected attribute question