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

$expand should be allowed to return only ids for already seen objects

    Details

    • 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]

      Description

      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.

        Attachments

          Activity

          Hide
          hubert.heijkers Hubert Heijkers (Inactive) added a comment -

          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?

          Show
          hubert.heijkers Hubert Heijkers (Inactive) added a comment - 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?
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          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.

          Show
          mikep Michael Pizzo (Inactive) added a comment - 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.
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          This ends up being closely related to Deltas; I would like to have the Delta discussion before addressing this issue.

          Show
          mikep Michael Pizzo (Inactive) added a comment - This ends up being closely related to Deltas; I would like to have the Delta discussion before addressing this issue.
          Hide
          mikep Michael Pizzo (Inactive) added a comment -

          still need to apply to abnf

          Show
          mikep Michael Pizzo (Inactive) added a comment - still need to apply to abnf

            People

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

              Dates

              • Created:
                Updated:
                Resolved: