Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-964

Need to clarify nested delta representation

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: V4.01_WD01
    • Component/s: Protocol
    • Labels:
      None
    • Environment:

      Proposal needed for CSD01

    • Proposal:
      Hide

      Added/Deleted links only appear at the root.

      Nested content with "#$delta" is applied as a delta. Entities are upserted, deleted entities are removed from the collection. If reason:deleted is specified, client knows the related entity is deleted, otherwise (in a non-containment case) all the client knows is that the entity is no longer a member of that collection. The contextUrl for the nested deleted entity is the same as it would be in the flattened representation.

      Show
      Added/Deleted links only appear at the root. Nested content with "#$delta" is applied as a delta. Entities are upserted, deleted entities are removed from the collection. If reason:deleted is specified, client knows the related entity is deleted, otherwise (in a non-containment case) all the client knows is that the entity is no longer a member of that collection. The contextUrl for the nested deleted entity is the same as it would be in the flattened representation.
    • Resolution:
      Hide

      Applied to [Core] and [JSON] documents.

      Show
      Applied to [Core] and [JSON] documents.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              mikep Michael Pizzo (Inactive)
              Reporter:
              mikep Michael Pizzo (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: