[OASIS Issue Tracker] (ODATA-964) Need to clarify nested delta representation

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

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

Michael Pizzo edited comment on ODATA-964 at 11/1/16 6:43 PM:
--------------------------------------------------------------

The things we can express in delta:
-Added member
-Update member
-Added Link
-Deleted member
-Deleted Link

The first three we already have semantics for in a nested payload.  For containment, the last two are identical.

One option might be to support the deleted entity in a nested payload but not added/deleted links. The deleted entity already has reasons for "deleted" and "changed"; we could use those to distinguish between a deleted entity and a deleted link in the non-nested case.  No supporting added/deleted links makes it easier to scope the support of the changes to the current nested collection (technically, a deleted entity could come from anywhere, but the semantics would be that it would no longer be a member of this collection, whether it ever was or not).

We still need to specify the context for the deleted entity. Perhaps we can require that it be the navigation property on the parent object, followed by the /$deletedEntity (i.e., Employees(1)/DirectReports/$deletedEntity in the above example), to emphasize that it is removed from this collection?  In a non-containment case you would only know that the item was deleted from its root collection if reason:deleted was specified, which I think is fine.


was (Author: mikep):
The things we can express in delta:
-Added member
-Update member
-Added Link
-Deleted member
-Deleted Link

The first three we already have semantics for in a nested payload.  For containment, the last two are identical.

One option might be to support the deleted entity in a nested payload but not added/deleted links. The deleted entity already has reasons for "deleted" and "changed"; we could use those to distinguish between a deleted entity and a deleted link in the non-nested case.  No supporting added/deleted links makes it easier to scope the support of the changes to the current nested collection (technically, a deleted entity could come from anywhere, but the semantics would be that it would no longer be a member of this collection, whether it ever was or not).

> Need to clarify nested delta representation
> -------------------------------------------
>
>                 Key: ODATA-964
>                 URL: https://issues.oasis-open.org/browse/ODATA-964
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>         Environment: Proposal needed for CSD01
>            Reporter: Michael Pizzo
>            Assignee: Michael Pizzo
>             Fix For: V4.01_WD01
>
>
> In OData-876 we defined a format for representing nested changes in-line within a delta format. In OData-613 we said you could use PATCH to update a collection using a delta format, and added the following to ODATA-876:
> "You can use contextUrl (ending in /$delta) on the navigation property to specify that the nested content is a delta content (partial update with patch semantics that can contain added/deleted links and tombstones)."
> The above text implies that you can have a delta format nested within a navigation property for an otherwise non-delta format. However, this brings up some issues, since the delta format was defined as a flat format. In particular, 
> 1) what is the format/content of the contextUrls required for added links, deleted links, and deleted entries
> 2) are there any restrictions on the scope of the added/delete links (and tombstones); do they have to be at all related to the nav prop?
> Option 1 would be to use contextUrls such as the following:
> { 
>   "@odata.type":"#Northwind.Manager",
>   "FirstName" : "Patricia",
>   "DirectReports@odata.contextUrl" : "#Employees(1)/DirectReports/$delta",
>   "DirectReports": [
>     {
>       "@odata.context":"#Employees/$deletedEntity",
>       "id":"Employees(3)",
>       "reason":"deleted"
>     },
>     {
>       "@odata.context":"#Employees/$deletedLink",
>       "source":"Employees(1)",
>       "relationship":"DirectReports",
>       "target":"Employees(4)"
>     },
>     {
>       "@odata.context":"#Employees(1)/$link",
>       "source":"Employees(1)",
>       "relationship":"DirectReports",
>       "target":"Employees(5)"
>     },
>     {
>       "@odata.context":"#Employees/DirectReports/$entity",
>       "FirstName": "Suzanne",
>       "LastName": "Brown"
>     }
>   ]
> }
> Option 2 would be to prohibit use of delta format for nested nav props within a non-delta format.



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