# Updating a DB entry without having to instantiate an object

**URL:** <https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894>\
**Category:** Rails\
**Created:** [May 17, 2008, 8:44pm UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894 "2008-05-17T20:44:58Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\
**Post date:** [May 17, 2008, 8:44pm UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894/1 "2008-05-17T20:44:58Z")

</div>

Hi,

I noticed that in order to use update\_attributes(), AR firsts needs to  
make a SELECT query to the DB to fetch the data, then AR creates an  
object from it, and then it issues the UPDATE statement.

What I am trying to do is update a field in the DB without having to do  
this preliminary SELECT (thus saving a query on my InnoDB table) and the  
subsequent ORM that will occur. Is it possible with AR? Or do I need to  
use my own custom SQL query?

---

<div class="post-metadata">

**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\
**Post date:** [May 17, 2008, 9:17pm UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894/2 "2008-05-17T21:17:32Z")

</div>

I don’t know if it’s possible, but I’d like to ask: Have you measured  
the performance of your app and found it to be unsatisfactory and the  
cause to be update\_attributes? If no, then just let update\_attributes  
do it’s thing. If yes, then I’m sure you’ll receive some helpful  
advice from those who know.

Regards,  
Craig

---

<div class="post-metadata">

**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\
**Post date:** [May 17, 2008, 10:06pm UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894/3 "2008-05-17T22:06:56Z")

</div>

Hi Craig, I know what you mean, but I prefer to have my app slightly  
optimized when it seems it is not yet required. I am sure that the  
claims about Rails being slow comes from people who rely too much on AR  
magics to handle SQL, and they don’t notice that they are making a pure  
mess with their DB server being hit too many times.

It is like talking about the n+1 problem, you don’t see its drawbacks  
when the DB is small, but you absolutely must get rid of it from the  
very beginning even if the current speed measured is satisfactory.

It’s by leaving small bits and pieces that will eventually pile up that  
you get a sluggish application.

---

<div class="post-metadata">

**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\
**Post date:** [May 17, 2008, 10:41pm UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894/4 "2008-05-17T22:41:35Z")

</div>

On May 17, 2008, at 2:44 PM, Fernando P. wrote:

> subsequent ORM that will occur. Is it possible with AR? Or do I need  
> to  
> use my own custom SQL query?

Have you looked at update\_all?

MyModel.update\_all([‘hair = ?, eye = ?’, ‘brown’, ‘green’],  
[‘full\_name = ?’, ‘Fernando P.’])

The first argument is the setting part of the SQL and the second  
argument is the where conditions. They are run through sanitize\_sql.  
It’s just one step away from

MyModel.connection.execute(“UPDATE my\_models SET hair = ‘brown’, eye =  
‘green’ WHERE full\_name = ‘Fernando P.’”)

-Rob

Rob B. [http://agileconsultingllc.com](http://agileconsultingllc.com)  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\
**Post date:** [May 17, 2008, 10:58pm UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894/5 "2008-05-17T22:58:03Z")

</div>

Rob is right, update\_all will take care of updating without  
instantiating.

I don’t believe, though, that update\_attributes itself triggers a  
select. More likely you’re seeing the select from initially  
retrieving the object on which you are calling update\_attributes.  
That is, if you’re looking at a typical update action from rails’  
scaffolding:

def update

# this line triggers the select

@my\_object = MyObject.find(params[:id])

# this line triggers the update

if @my\_object.update\_attributes(params[:my\_object])  
…  
end

The advantage you get here is that you can have business logic  
triggered from several different places: after\_save callbacks,  
ActiveRecord observers, etc. You may not need them now but at some  
point they’re likely to provide you some extra help that you’ll miss  
if you make a habit of bypassing update\_attributes.

Just a note… in 2.1 there IS a nice performance enhancement related  
to update\_attributes. Currently (2.0.x) update\_attributes always  
updates all the attributes even if you only submit a subset of  
attributes for updating. Rails 2.1 fixes this, only updating the  
‘dirty’ attributes.

On May 17, 4:40 pm, Rob B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\
**Post date:** [May 17, 2008, 11:46pm UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894/6 "2008-05-17T23:46:33Z")

</div>

AndyV wrote:

> Rob is right, update\_all will take care of updating without  
> instantiating.  
> Exactly, thank you Rob.

> # this line triggers the update
> 
> if @my\_object.update\_attributes(params[:my\_object])  
> …  
> end  
> In order to to the update this way, you first must do a SELECT.

I tried also MyModel.update(), and it also issues a SELECT before making  
the update.

Using Rob’s MyModel.update\_all() simply does the UPDATE without anything  
else.

> The advantage you get here is that you can have business logic  
> triggered from several different places: after\_save callbacks,  
> ActiveRecord observers, etc. You may not need them now but at some  
> point they’re likely to provide you some extra help that you’ll miss  
> if you make a habit of bypassing update\_attributes.  
> The models in which I need validation or callbacks use the regular  
> update\_attributes, in this very particular case, there is no need for  
> initially fetching from DB.

> Just a note… in 2.1 there IS a nice performance enhancement related  
> to update\_attributes. Currently (2.0.x) update\_attributes always  
> updates all the attributes even if you only submit a subset of  
> attributes for updating. Rails 2.1 fixes this, only updating the  
> ‘dirty’ attributes.  
> At last they did it! That is excellent. Where did you find the changelog  
> about the new features of 2.1?

Best regards,

---

<div class="post-metadata">

**Author:** ![fipa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/9e8a1a/32.png) [@fipa](https://www.ruby-forum.com/u/fipa)\
**Post date:** [May 18, 2008, 4:13am UTC](https://www.ruby-forum.com/t/updating-a-db-entry-without-having-to-instantiate-an-object/137894/7 "2008-05-18T04:13:10Z")

</div>

> At last they did it! That is excellent. Where did you find the changelog  
> about the new features of 2.1?

I just follow the guys who are playing with the latest toys:

> **[A smattering of engineering, technology, and related stuffs](https://www.ryandaigle.com)**
>
> A smattering of engineering, technology, and related stuffs
