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

Do we need a way to distinguish between properties that are omitted due to being aggregated away versus those that don't apply (i.e., in a concatenated result)?

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_CSD01
    • Fix Version/s: V4.0_CSD02
    • Component/s: Data Aggregation
    • Labels:
      None
    • Environment:

      [Proposed][Applied]

    • Proposal:
      Hide

      @odata.context allows to identify and distinguish all cases: aggregation result, rollup entities, concat result.

      • The @odata.context describes the properties from the input set that remain in the result after aggregation. Any property of the input/expanded sets not listed here has been aggregated away.
      • In rollup entities, one or more of those properties are omitted. Comparing an instance with the surrounding @odata.context, the absence of a property in an instance classifies this entity as rollup entities, because there is no other way how a property could get lost.
      • Concat combines two aggregated results with potentially different structures as a single result collection. This inhomogeneous structure cannot be described with a single context URL at the level of the collection. If the two partial results deviate structurally, the current JSON spec requires a provider to apply @odata.context at entity instance level for every entity. This is not efficient if done for a large set of such instances, but we do not see any other option with the current capabilities of @odata.context. On the other hand, every part of the result structure is clearly defined, so there's need to further distinguish the cases mentioned in the issue.

      Close without action

      Accepted: https://www.oasis-open.org/committees/download.php/51905/odata-meeting-64_on-20140109-minutes.html#odata-577

      Show
      @odata.context allows to identify and distinguish all cases: aggregation result, rollup entities, concat result. The @odata.context describes the properties from the input set that remain in the result after aggregation. Any property of the input/expanded sets not listed here has been aggregated away. In rollup entities, one or more of those properties are omitted. Comparing an instance with the surrounding @odata.context, the absence of a property in an instance classifies this entity as rollup entities, because there is no other way how a property could get lost. Concat combines two aggregated results with potentially different structures as a single result collection. This inhomogeneous structure cannot be described with a single context URL at the level of the collection. If the two partial results deviate structurally, the current JSON spec requires a provider to apply @odata.context at entity instance level for every entity. This is not efficient if done for a large set of such instances, but we do not see any other option with the current capabilities of @odata.context. On the other hand, every part of the result structure is clearly defined, so there's need to further distinguish the cases mentioned in the issue. Close without action Accepted: https://www.oasis-open.org/committees/download.php/51905/odata-meeting-64_on-20140109-minutes.html#odata-577

      Description

      There appear to be (at least) two ways a property may be omitted from an aggregated result:
      1) The property may be omitted because it has been aggregated away (i.e., in a rollup)
      2) The property may be omitted because an operator has been applied (i.e., concat) that leaves certain properties undefined for certain rows

      Do we need a property annotation for either (or both) so that clients can distinguish between properties being omitted because they were aggregated away versus because they didn't apply?

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: