How do I stop a column being updated by model.save?

#1

One of my models has a column that is updated very frequently from a
separate process, so it is important that when a record is saved in
rails, this column should be left alone. In the update method of the
controller I have:

@record = MyModel.find(params[:id])
@record.update_attributes(params[:my_model])

params[:my_model] doesn’t have a reference to the column I’m talking
about, however, the UPDATE statement produced by update_attributes will
still assign a value to this column.

Even though its unlikely, if the separate process updates the record in
the time betweent the find, and the update, then the new value will be
lost. Is there a way to prevent this from happening?

p.s. attr_protected doesn’t help me

#2

On 5/21/07, David F. removed_email_address@domain.invalid wrote:

about, however, the UPDATE statement produced by update_attributes will
still assign a value to this column.

Even though its unlikely, if the separate process updates the record in
the time betweent the find, and the update, then the new value will be
lost. Is there a way to prevent this from happening?

One option, not very clean and elegant, and probably prone to
deadlocks if you update several rows during a transaction, is locking
the row & reading its’ current value from a before_save callback.

E.g.:

def before_save
unless self.new_record?
current = self.class.find(self.id, :lock => true) # “select for
update”, locking row
write_attribute(:some_attribute, current.some_attribute)
end
end

Isak

#3

def before_save
unless self.new_record?
current = self.class.find(self.id, :lock => true) # “select for
update”, locking row
write_attribute(:some_attribute, current.some_attribute)
end
end

Isak

Its nasty, but it might work. Thanks!

#4

On May 21, 2007, at 10:19 AM, David F. wrote:

about, however, the UPDATE statement produced by update_attributes
will
still assign a value to this column.

Even though its unlikely, if the separate process updates the
record in
the time betweent the find, and the update, then the new value will be
lost. Is there a way to prevent this from happening?

p.s. attr_protected doesn’t help me

The invocation is

attr_readonly :foo

but according to

http://dev.rubyonrails.org/ticket/6896

is scheduled for 1.2.4.

– fxn

#5

@record.update_attribute(“your_column”, params[:value])

This has the same problem, both “update_attribute” and
“update_attributes” call the “save” method, which in turn, calls the
“update” method. This is whats setting the values of all the columns in
the table.

#6

hi david,

have you ever try this:
@record = MyModel.find(params[:id])
@record.update_attribute(“your_column”, params[:value])

for updating several column, you could use this instead:
@record.update_attribute(“your_column1”, params[:value1],
“your_column2”,
params[:value2])

afaik, if you do somethink like this:
@record.update_attributes(params[:value])

then all your column will be updated using apt column-name with array of
:value, so that you previous value of column will be lost regardles.

regard,

~inung;

On 21/05/07, David F. removed_email_address@domain.invalid wrote:

Isak

Its nasty, but it might work. Thanks!

–
Posted via http://www.ruby-forum.com/.

–
in03ng a.k.a inung a.k.a nursamsi a.k.a nur syamsi
Y! in03ng

#7

Yes, both attr_protected and attr_accessible only allow/prevent values
being assigned at the Rails level, the underlying SQL UPDATE that is
executed is still updating the values of all the columns.

Thanks anyway for trying!

#8

David F. wrote:

still assign a value to this column.

Even though its unlikely, if the separate process updates the record in
the time betweent the find, and the update, then the new value will be
lost. Is there a way to prevent this from happening?

p.s. attr_protected doesn’t help me

Check out optimistic locking.

–
Jack C.
removed_email_address@domain.invalid

#9

sorry david, i’m wrong getting your first message. anyway, have u ever
try
using attr_accessible? n00b here, just trying to help…:smiley:

regards,

~inung;

On 21/05/07, David F. removed_email_address@domain.invalid wrote:

Posted via http://www.ruby-forum.com/.

–
in03ng a.k.a inung a.k.a nursamsi a.k.a nur syamsi
Y! in03ng