-
Type:
Improvement
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: V4.0_WD01
-
Fix Version/s: V4.0_WD01
-
Component/s: ATOM Format, JSON Format
-
Labels:None
-
Environment:
[Proposed]
-
Proposal:
-
Resolution:
Today, specifying $expand may return the same item multiple times. For example, if the someone is really popular, selecting ~people/$expand=friends may return the same friend for multiple people. This can lead to payload bloat when attempting to select a graph of related entities.
A simple means of compression would be to allow the service to return only the id of related entities that have already been returned within a feed. This would work nicely for existing clients that track incoming entities as they generally already have logic to merge with or simply return previously retrieved objects.
We might consider a preference to allow the client to request whether or not duplicate ids are returned in full, and pick a default behavior for the service if the client doesn't specify a preference. We could use the defined return=minimal for this; currently this is used in PUT/POST to say don't return results if they haven't changed, but are undefined for a GET operation in OData.
We are working on a proposal for a flattened result set in order to resolve ordering problems around deltas, which would also eliminate the potential redundancy in serializing a graph hierarchically. We might want to wait on that proposal before considering this.
This ends up being closely related to Deltas; I would like to have the Delta discussion before addressing this issue.
| Field | Original Value | New Value |
|---|---|---|
| Environment | [Proposed] |
| Proposal |
Allow services to return only the id of related entities that have already been returned within a feed. In json, this would be an object containing only the id field. in atom this would be an entry with the following required fields: id, title, updated and author. If the client specifies return=minimal, return only the ids of related entities that have already been returned within the same feed. |
Propose we support Entity References as described in: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/48082/latest |
| Environment | [Proposed] |
| Status | New [ 10000 ] | Open [ 1 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Proposal | Propose we support Entity References as described in: https://www.oasis-open.org/apps/org/workgroup/odata/download.php/48082/latest |
Propose we support Entity References as described in https://www.oasis-open.org/apps/org/workgroup/odata/download.php/48082/latest with a preference of odata.allow-references Accepted: https://www.oasis-open.org/committees/download.php/48097/odata-meeting-23_on-20130130_31-F2F-minutes.html#odata-199 |
still need to apply to abnf
| Fix Version/s | WD01 [ 10247 ] | |
| Affects Version/s | WD01 [ 10247 ] |
I suppose it would be fair to presume that the first occurrence of an entity would be returned correct. What would happen if we have the same entity type at multiple levels? For example, in the example above with people and their friends, presuming friends are people as well, what would happen if a friend, that occurs more then once as a friend of other people, is in the set of people as well? Would I only see the complete entity of that person/friend at the people level only, at the friend level if that particular person was referenced as a friend before his occurrence in the people set or both? Not to be leading but I'm guessing the latter also because the projection of the entities at the various levels could be different as well correct?