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 -~----------~----~----~----~------~----~------~--~---
