[OASIS Issue Tracker] (ODATA-1148) PATCH with nested nav props should not remove omitted resources

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/ODATA-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=69124#comment-69124 ] 

Steven Legg commented on ODATA-1148:
------------------------------------

The inconsistency is in 4.0 where properties, collection properties and navigation properties all have replace semantics in a PATCH, but collection navigation properties are additive. This anomaly has not only tripped up myself and my colleagues more than once, it is also an annoyance when attempting to synchronize the content of an entity from some external data source or to return it to a previous state. The properties, collection properties and navigation properties can all be set to the required values in a single PATCH request, but each collection navigation property has to be stripped out of the PATCH request and submitted as a separate PUT request. To avoid this inconvenience I resorted to a private bind annotation that was like the standardized bind but with replace semantics. 

Version 4.01 is much better in that I can synchronize or reset the content of an entity, including the collection navigation properties, with a single PATCH request and without using a private annotation.

> PATCH with nested nav props should not remove omitted resources
> ---------------------------------------------------------------
>
>                 Key: ODATA-1148
>                 URL: https://issues.oasis-open.org/browse/ODATA-1148
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: JSON Format, Protocol
>    Affects Versions: V4.01_CS01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.01_CS02
>
>
> In OData 4.0 we explicitly disallowed deep updates (i.e., including related entities in a PUT or PATCH request).  We did allow binding (through the @bind annotation).
> In OData 4.01 we added the ability to do deep updates, but we are inconsistent with how we describe the behavior.
> In the Protocol document we say that the nested content replaces the existing content, removing any related resources not specified in the payload:
> 11.4.3.1 Update Related Entities When Updating an Entity (Protocol)
> …
> Payloads with an OData-Version header with a value of 4.01 or greater MAY include nested entities and entity references that specify the full set of currently related entities, or a nested delta payload representing the related entities that have been added, removed, or changed.
> If the nested collection is represented identical to an expanded navigation property, then the set of nested entities and entity references specified in a successful update request represents the full set of entities to be related according to that relationship and MUST NOT include added links, deleted links, or deleted entities.
> However, this is different than the semantics we describe in section 8.5 of the JSON document (taken from 4.0), which says that the bound items are added, and don't affect the existing relationships:
> 8.5 Bind Operation (JSON)
> …
> For update operations a bind operation on a collection navigation property adds additional relationships, it does not replace existing relationships, while bind operations on an entity navigation property update the relationship.
> In fact, for a PATCH operation, most people expect that the membership of the collection-valued nav prop is not replaced, but that specified resources are added or updated.
> It would probably be more intuitive to say that PATCH updates the service with the references in the payload, and that PUT must be used in order to do the replace semantics, or @delta can be used to remove (or upsert) individual entries.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)