Forum: Ruby on Rails Read-only fields.

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.
860dc779f0007a35bdcd12b5fc9eb589?d=identicon&s=25 Dean Holdren (Guest)
on 2007-04-18 17:38
(Received via mailing list)
I have a field in my table that I do not want ActiveRecord to update.
I would like to retrieve that field, and have it displayed.

However, when I perform update, and ActiveRecord generates the SQL, I
don't want it to include the field in it's update. I haven't figured
out a way to do this.

Any ideas?
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2007-04-18 17:54
(Received via mailing list)
On Apr 18, 2007, at 5:37 PM, Dean Holdren wrote:

> I have a field in my table that I do not want ActiveRecord to update.
> I would like to retrieve that field, and have it displayed.
>
> However, when I perform update, and ActiveRecord generates the SQL, I
> don't want it to include the field in it's update. I haven't figured
> out a way to do this.

If the attribute is only updated under the hood, with triggers,
Model.update_all, etc. then

   attr_readonly :foo

is what you need, but according to

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

is scheduled for 1.2.4 (I thought it was accepted for 1.2).

-- fxn
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2007-04-20 04:13
(Received via mailing list)
Dean Holdren wrote:

> I have a field in my table that I do not want ActiveRecord to update.
> I would like to retrieve that field, and have it displayed.
>
> However, when I perform update, and ActiveRecord generates the SQL, I
> don't want it to include the field in it's update. I haven't figured
> out a way to do this.

Why not write unit tests that check the value never changes, then write
it
liberally? Who cares if the magnetism actually hits that database file
storage block, if the users never see the difference?

DBs were not made for the C++ 'const' concept...

--
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2007-04-20 08:59
(Received via mailing list)
On Apr 20, 2007, at 4:11 AM, Phlip wrote:

> storage block, if the users never see the difference?
Problem are race conditions:

   1. user = User.find(id)

   2. another process udates his record

   3. user.save

Now the field is overwritten with the previous value, so the record
is broken. Even if you perform an extra read from the database in a
before_save to get the value at that moment there's risk for a race
condition.

In a muti-process environment there are race conditions if you don't
lock resources, but if the data is updated always by actions the
heuristic "last update wins" is normally good enough. When there are
updates that only come from the database that doesn't apply.

-- fxn
6ef8cb7cd7cd58077f0b57e4fa49a969?d=identicon&s=25 Brian Hogan (Guest)
on 2007-04-20 15:51
(Received via mailing list)
Xavier: Most of those are solved with a lock_version field and
optimistic
locking. However, there are other conditions where a bulk update might
not
be ideal.
7223c62b7310e164eb79c740188abbda?d=identicon&s=25 Xavier Noria (Guest)
on 2007-04-20 17:45
(Received via mailing list)
On Apr 20, 2007, at 3:50 PM, Brian Hogan wrote:

> Xavier: Most of those are solved with a lock_version field and
> optimistic locking. However, there are other conditions where a
> bulk update might not be ideal.

There are situations where you have an attribute that is _always_
maintained outside AR. There, optimistic locking is not what you
need. To program that way you need to catch an exception, reload that
special value, preserve the rest, and loop until eventually some save
succeeds. That's cumbersome.

What you really need is a transparent solution that provides a
regular model.save that ignores the field altogether. That's why
there's a patch to add attr_readonly in the cue.

-- fxn
6ef8cb7cd7cd58077f0b57e4fa49a969?d=identicon&s=25 Brian Hogan (Guest)
on 2007-04-20 17:54
(Received via mailing list)
Yup, I agree 100%. That's just one of the many  "other conditions" I
hinted
at.  I misinterpred your example (another process) to mean the same
program,
not an outside entity.
This topic is locked and can not be replied to.