OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Michael Pizzo commented on ODATA-876:

Updated proposal to address the fact that the inline collection may be filtered (so removed items are not necessarily deleted). Simplified the special cases by saying the resources could only be inline if the members of the related collection were not otherwise referenced by the defining query (I expect this to be the common case, and this restriction makes it significantly easier to explain the semantics of removing an item from a filtered collection as simply saying "if it still exists, it's not something you said you cared about so you won't hear any more about it," rather than having complicated rules that the client (and service) has to follow for knowing when they will/will not get additional notifications).

> 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 JSON Format
>    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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]