[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=63165#comment-63165 ] 

Matthew Borges commented on ODATA-964:
--------------------------------------

I definitely think if we allow the nested add/delete links it needs to be in the scope of the navigation property.  However, it's unclear to me why that would be needed.  If the client is smart enough to detect individual changed relationships and changes to specific related entities what value does the nesting add to the flat delta payload?  Where I could see the nesting being useful is the case where the client cannot determine specific changes and needs to send a snapshot of the current related entities but in this case you wouldn't need deleted or added links.

> 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
>            Reporter: 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)