[OASIS Issue Tracker] (ODATA-876) Allow services to return contained entities inline for delta responses

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

Michael Pizzo created ODATA-876:
-----------------------------------

             Summary: Allow services to return contained entities inline for delta responses
                 Key: ODATA-876
                 URL: https://issues.oasis-open.org/browse/ODATA-876
             Project: OASIS Open Data Protocol (OData) TC
          Issue Type: Bug
          Components: OData Extension for JSON Data
    Affects Versions: V4.0_ERRATA02
         Environment: [Proposed]
            Reporter: Michael Pizzo
             Fix For: V4.01_WD01


In a delta response for an expanded query we return a flattened result that includes any nested entities that have been added/changed/deleted, along with added/deleted links as appropriate.

We did this rather than returning expanded content in-line because the semantics of including them inline are unclear; does it mean that only the included inline elements changed, or is it a replacement for the entire set?  How do you represent a deletion of a related entity versus simply removing the relationship to that entity – do you have to have a deleted entry in the current collection for deletions? And what if that deleted entity had related entities, some of which were also changed/deleted; how do you return those in a nested result? 

We generally allow the service to track only that a change has occurred to a given item, not what changed within that item. However, a store may well track contained items along with the entity and not be able to tell whether the set of contained items changed, only that a change occurred somewhere in the containment hierarchy.

For collections of non-entity types we say that the collection is treated as an atomic value – that, if present, the members represent the full membership of the collection. Services don't have to track individual changes to the collection, they just have to know that something changed and they can give the current membership of the collection.

We could say the same thing for containment navigation properties – that expanding them in-line means that the set of returned entities represents the full set of contained entities, and any previous entities not listed (and all relationships) are implicitly deleted. The client already has to delete contained entities when the parent is deleted so this shouldn't be too onerous. 

We could consider allowing this for non-containment navigation properties, with the semantic that entities omitted from the collection were no longer related (but not deleted), but any related entities that *were* deleted would have to also be returned as (non-nested) deleted entities, and any changed entities/relationships nested below that deleted entity would have to be separately represented in the payload.



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