Forum: Ruby on Rails update_attribute send updates every field, why?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B9a732fc30c32098347a0177c75ee27b?d=identicon&s=25 jeroen (Guest)
on 2005-11-17 12:54
(Received via mailing list)
Hi,

If you do model.update_attribute("fname", "John") the every field is
updated, it generates a big update statement like:

update persons set fname=x, lname=y, email=z, whatever=blah,
and_stuff=stuff where id=1

I would think it would just generate:
update persons set fname='John' where id=1

Anybody know why AR acts this way?

Jeroen
C64e63b70be7dfed8b0742540b8b27e5?d=identicon&s=25 mrj (Guest)
on 2005-11-18 13:11
(Received via mailing list)
Jeroen Houben wrote:
>
> Anybody know why AR acts this way?

I think that's just the Rails does it.  Records are always
saved in their entirety.

I've found the following simple Active Record extentions to be
helpful in cutting out some useless database activity:


class ActiveRecord::Base
   def changed(attrs)
     return false if attrs.nil?
     self.class.content_columns.each { |c| return true if self[c] !=
attrs[c] }
     return false
   end

   def update_attributes_if_changed(attrs)
     changed(attrs) ? update_attributes(attrs) : true
   end

   def update_attribute_if_changed(name, value)
     self[name] != value ? update_attribute(name, value) : true
   end
end


--
We develop, watch us RoR, in numbers too big to ignore.
B9a732fc30c32098347a0177c75ee27b?d=identicon&s=25 jeroen (Guest)
on 2005-11-18 17:13
(Received via mailing list)
Mark Reginald James wrote:
>> I would think it would just generate:
>
>     changed(attrs) ? update_attributes(attrs) : true
>   end
>
>   def update_attribute_if_changed(name, value)
>     self[name] != value ? update_attribute(name, value) : true
>   end
> end
>
>

This doesn't address my original problem though, right? I mean in the
end you still call  update_attribute which generates the full update
SQL, not just for one field. Or am I missing something here...

Jeroen
C64e63b70be7dfed8b0742540b8b27e5?d=identicon&s=25 mrj (Guest)
on 2005-11-19 01:28
(Received via mailing list)
Jeroen Houben wrote:

> This doesn't address my original problem though, right? I mean in the
> end you still call  update_attribute which generates the full update
> SQL, not just for one field. Or am I missing something here...

Yes, as I wrote, unless you do custom SQL, Rails always saves entire
records.
The code I gave was just a way to cut out unnecessary saves in certain
circumstances.

I'm not sure whether entire records are saved to simplify the Rails
code,
or because of some tricky issues that would arise if attributes could
be updated individually.  At the least you'd probably have to add a
dirty
bit to each record, or to each attribute in each record.

--
We develop, watch us RoR, in numbers too big to ignore.
C75c0ea69a57d3e8c48956004f27a604?d=identicon&s=25 GeekEntrepreneu (Guest)
on 2005-12-23 14:34
(Received via mailing list)
I too am observing this. Can anyone throw some light on this behaviour?
5ceea097a3b29cb6a5da6705926410f4?d=identicon&s=25 Gerret Apelt (Guest)
on 2005-12-23 14:55
(Received via mailing list)
>From ActiveRecord::Base:

     def update_attribute(name, value)
        send(name.to_s + '=', value)
        save
      end
     def save
        raise ActiveRecord::ReadOnlyRecord if readonly?
        create_or_update
      end

The call to 'create_or_update' will trigger either object#create or
object#update, each of which contains the SQL code that persists the
attributes in the object. You could probably   override
update_attribute, and have it call a new method
'create_or_update_lone_attribute' instead of 'save'. Doesnt look like
that would break anything.

On the other hand, why? Unless you have some huge binary columns, the
db will update n columns in a record just about as quick as a single
column.

cheers
Gerret
This topic is locked and can not be replied to.