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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs