Rails core - Aug 2012 - Question about PATCH method, accepts_nested_attributes_for, and updates to association lists (has_many, HABTM)

Am interested in the new PATCH method that will be included in Rails 4, but 
have a question/concern, and forgive me if I''m misunderstanding it.

So, if the request parameter _method is set to "patch", the update is 
processed as a patch.

But, let''s say you have a model called Airplane and Airplane has a 
collection of FlightCrewMembers which it accepts_nested_attributes_for. You 
get the Airplane resource via a RESTful call to Rails that contains the 
FlightCrewMembers list. Then something needs to make a PATCH to this 
resource and change both an attribute called autopilot_engaged on the 
Airplane while only changing the active_pilot flag of one of the 
FlightCrewMembers. You send this together to ensure that a single 
transaction is wrapped around both the update to autopilot_engaged on the 
Airplane and the active_pilot flag of one of the FlightCrewMembers.

When you send the Airplane resource from the client to the RESTful service, 
you specify one or more FlightCrewMembers in the resource. If you truly 
wanted to patch, you should only have to specify the one FlightCrewMember 
in the Airplane''s list of FlightCrewMembers and only specify the 
active_pilot flag on that FlightCrewMember. However, this could also 
indicate that the other 4 of the 5 FlightCrewMembers are no longer on the 
plane if the patch is also allowed to change which FlightCrewMembers are 
assocated with the Airplane. But that would mean you''d have to specify
the
list of ids of FlightCrewMembers in the patch request, which could have the 
unintended result of altering the list of members if one member had really 
left the plain at the same time (perhaps they are still on the ground and 
one just left the Airplane to run up the jetway).

So, does there need to be new attributes on the Airplane resource that is 
passed in by the client to indicate whether the membership list of 
FlightCrewMembers is being altered on Airplane? And instead of just passing 
in a list of objects that only specify the id of the associated object to 
update the list, shouldn''t the client (since they are providing a
patch) be
able to only specify which members are be deleted?
 
Possibly support could be added for a new _remove key on the object to be 
removed from a list? That would seem to be a good name. That way you could 
either use the existing _destroy key that allows you to destroy the 
associated object or could use the new _remove key to just indicate that in 
your patch request you are specifying to remove it from the list.

So, if the _method were "patch", then just specifying a list of
objects
only indicating their IDs wouldn''t update the membership of that
resource''s
collection. You would need to specify a _remove or _destroy key (depending 
on whether the client wanted to just remove it from the collection or 
actually destroy the object).
 

-- 
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/-/PvCRFrUc5e8J.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

This is the reason that the spec for patch[1] specifically requires a
diff be sent[2]:
> The set of changes is represented in a format called a "patch
> document" identified by a media type.
and
> With PATCH, however, the enclosed entity contains a set
> of instructions describing how a resource currently residing on the
> origin server should be modified to produce a new version.
and
> Further, it is expected that different patch document formats will be
> appropriate for different types of resources and that no single
> format will be appropriate for all types of resources.  Therefore,
> there is no single default patch document format that implementations
> are required to support.
If you plan to use PATCH, you should figure out what you need and use
it. I''m not aware of a media type that does diffs in plain JSON at
this time.

1: http://tools.ietf.org/html/rfc5789
2: http://tools.ietf.org/html/rfc5789#section-2

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Steve,

Thanks for your response!

If you plan to use PATCH, you should figure out what you need and use
it.
>
I had read: 
http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-primary-http-method-for-updates/

It states that:

Because of that, the PATCH
<http://www.rfc-editor.org/rfc/rfc5789.txt>method was defined in 1995 and
standarized later. PATCH is a method that is 
> not safe, nor idempotent, and allows *full and partial updates* and
*side-effects
> on other resources*. In practice, as you see, PATCH suits everyday web 
> programming way better than PUT for updating resources. In Ruby on Rails it
> corresponds naturally to the way we use update_attributes for updating 
> records. Thus, PATCH is going to be the primary method for updates in Rails
> 4.0.
>
Rails supports use of accepts_nested_attributes_for to update associated 
models, so I''m curious how these patches could be accomplished easily
in
Rails 4:

1. What would a JSON request look like that could be sent into a controller 
via patch method to only change one field in an associated model, where the 
model being updated accepts_nested_attributes_for the model that has the 
field you want to update?

2. What would a JSON request look like that could be sent into a controller 
via patch method to only remove a single tie record to an association 
without changing the list of associations, to avoid losing other changes 
that have been made to the membership of the collection/list of 
associations? (Does patch require a _destroy on a tie/connecting model? If 
so, would that be bad terminology considering that changes to associations 
as pointed out in http://guides.rubyonrails.org/association_basics.html for 
the Appointment tie models between Physician and Patient is deleted and not 
destroyed when there is a has_many :through relationship and the membership 
list is updated? In that case would a new _remove key on the associated 
model make sense?)

I''m basically just trying to understand what Rails 4 plans to offer
with
regard to patching, especially in the context of Javascript frameworks and 
the like that would be wanting to send/receive JSON to Rails controllers to 
manage not only models, but models and their associations. Just changing 
each model via its own request requires more requests and if there are 
changes that need to be made to specific fields of a model and specific 
fields of its associations in a single transaction, it would be much easier 
to just being able to send in a single patch request to a model that 
defines accepts_nested_attributes_for.

Thanks!
Gary


On Monday, August 13, 2012 6:20:25 PM UTC-4, Steve Klabnik
wrote:
>
> This is the reason that the spec for patch[1] specifically requires a 
> diff be sent[2]: 
>
> > The set of changes is represented in a format called a "patch 
> > document" identified by a media type. 
>
> and 
>
> > With PATCH, however, the enclosed entity contains a set 
> > of instructions describing how a resource currently residing on the 
> > origin server should be modified to produce a new version. 
>
> and 
>
> > Further, it is expected that different patch document formats will be 
> > appropriate for different types of resources and that no single 
> > format will be appropriate for all types of resources.  Therefore, 
> > there is no single default patch document format that implementations 
> > are required to support. 
>
> If you plan to use PATCH, you should figure out what you need and use 
> it. I''m not aware of a media type that does diffs in plain JSON at
> this time. 
>
> 1: http://tools.ietf.org/html/rfc5789 
> 2: http://tools.ietf.org/html/rfc5789#section-2 
>
-- 
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/-/YfYQDwoTeB0J.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> I''m basically just trying to understand what Rails 4 plans to
offer with
> regard to patching,
Here is the relevant commit: https://github.com/rails/rails/commit/002713c64

The commit message gives a pretty decent overview. This is basically
just a baby-step forward; but adding direct support for the method
will allow other people to do exactly what they want.

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> Should I put in a ticket for that?
This is exactly where feature requests go. So you kinda already did. ;)
> 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.
Yep. I''ve been giving some though to declaring some sort of
''Rails
flavored JSON'' that would be able to address these kinds of issues,
but it''s not near the proposal stage yet. We don''t know what
every
application needs, so currently, it''s left up to each dev.
> 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
Again, this is the reason why PATCH requires a diff media type be sent
to it. Then there''s no question.

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Steve, I''d be interested in this "Rails JSON media type" as
well, but we
can talk this weekend in Berlin. There is definitely a common behaviour 
that a lot of Rails projects would appreciate for a CRUD-style PATCH where 
the media type defines what will get overwritten, deleted, updated, also, 
with nested models, etc. Defining a media type would help Rails 
understanding that REST is not exposing a CRUD API through JSON.

Nick

On Tuesday, August 14, 2012 5:45:32 PM UTC+2, Steve Klabnik
wrote:
>
> > Should I put in a ticket for that? 
>
> This is exactly where feature requests go. So you kinda already did. ;) 
>
> > 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.
>
> Yep. I''ve been giving some though to declaring some sort of
''Rails
> flavored JSON'' that would be able to address these kinds of
issues,
> but it''s not near the proposal stage yet. We don''t know
what every
> application needs, so currently, it''s left up to each dev. 
>
> > 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 
>
> Again, this is the reason why PATCH requires a diff media type be sent 
> to it. Then there''s no question. 
>
-- 
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/-/B-YVBciO6RUJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Just showed up on HN: 
http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-03

Anyone here take part in that? Looks like would be good to support in Rails.

-- 
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/-/eB_qTeA78YIJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Related HN discussion: http://news.ycombinator.com/item?id=4478627

On Wednesday, September 5, 2012 10:34:56 AM UTC-4, Gary Weaver
wrote:
>
> Just showed up on HN: 
> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-03
>
> Anyone here take part in that? Looks like would be good to support in 
> Rails.
>
-- 
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/-/4fC2G2ZJ5dkJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Mark Nottingham (who''s the editor for HTTP 2.0) blogged about this
today as well: http://www.mnot.net/blog/2012/09/05/patch

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Thanks!

Moved discussion to new thread "Please add support for IETF 
"application/json-patch" media type":
https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-core/uuc6YmEb_XE


On Wednesday, September 5, 2012 10:39:03 AM UTC-4, Steve Klabnik
wrote:
>
> Mark Nottingham (who''s the editor for HTTP 2.0) blogged about this
> today as well: http://www.mnot.net/blog/2012/09/05/patch 
>
-- 
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/-/imJSWGflRJIJ.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.