I realize this issue has sort of been laid to rest but I just wanted to chime in and raise the viewpoint that Peter's description of his custom method "update_column" is really what a method named "update_attribute" should be doing as opposed to updating all the columns.
Regardless of whether or not validation should be called the current behavior adversely impacts save situations that involve concurrency and isn't of any added value for save situations that don't. Perhaps I'm missing legitimate reasons for this behavior? I too am facing the same situation as Peter. Wishing to update a flag that isn't user editable in a table that contains other user editable data. I'm going to write the same custom method as Peter has but again looking at the name "update_attribute" and knowing what it does in practice feels a little disingenuous :-) Best regards, -Michael http://javathehutt.blogspot.com On Mar 5, 2007, at 10:19 AM, Peter Marklund wrote: > > On Mar 4, 8:35 pm, Jamis Buck <[EMAIL PROTECTED]> wrote: >> Lots of people are depending on the current behavior. The method >> wasn't added arbitrarily, or in a fit of spite, it was extracted from >> real use, just like the rest of Rails. I use it all the time as a >> "update this flag in spite of the validations" scenario. > > Yeah, I understand that changing at this point can be problematic, but > maybe it's still worthwhile in the long run. To me, the clearest > syntax would be something like > > object.update_attribute(:attribute, value, :validate => false) > > Either way, I think I understand now the use case that this method > comes from now, and I've actually had it myself. In my case it was a > scheduled procedure that needed to update a single flag or date > column. What I ended up doing was hand writing my own method called > update_column which only updated that single column. The reason I > didn't use update_attribute was that it updates *all* columns which > lead to locking/concurrency issues. As far as I can tell, the ideal > implementation of this use case is a method that updates only the > column that you are interested in, but that *does* in fact trigger > validation but only validation for that particular column. > > I have yet to come across a use case where I need to set a column to a > value that by itself is invalid (i.e. setting a date to something that > is not a date, setting a string that can only have an enumeration of > values to something else etc.). It's a different issue that the set of > values for all attributes should be allowed to be invalid which I > think is what DHH and Jamis are referring to. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
