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? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 20, 2007, at 4:11 AM, Phlip 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?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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. On 4/20/07, Xavier Noria <fxn-xlncskNFVEJBDgjK7y7TUQ@public.gmane.org> wrote:> > > On Apr 20, 2007, at 4:11 AM, Phlip 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? > > 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 > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. On 4/20/07, Xavier Noria <fxn-xlncskNFVEJBDgjK7y7TUQ@public.gmane.org> wrote:> > > 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 > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---