Steve, Thanks! I was under the impression that patch might actually allow patch updates in some planned future version of Rails 4 by only specifying attributes (and attributes of associated models through accepts_nested_attributes_for) that the client requests to update.
If everything is being directed to the update method and then it doesn't support actually making patches, that seems like it would mislead more than it would actually provide desired functionality. I'm not suggesting PATCH be removed, but it would be nice if implementing patching behavior were on the roadmap. Should I put in a ticket for that? If you are trying to do a patch, then JSON in the request could be easily converted to model representation in Rails. But just handling off the implementation of a patch to the developer leaves a lot up in the air. For example, when parsing a patch, it would seem that there would be some way to differentiate between the incoming PATCH request specifying an attribute as nil vs. not specifying the attribute at all in the request (and therefore not wanting to set that attribute to nil). While this could be handled more simply, if you leave it up to the average developer, they might end up writing their own JSON parser and monkey-patching Object to add an "undefined" method to return some new Undefined class, so that it would appear to be part of syntax until an new type of nil could be added to Ruby called "undefined", which would probably never be added... In other words, I think handling this sort of thing would be better done on the Rails side. Gary -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/D6RVDkM-AIgJ. 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.
