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

Clarify location of custom aggregates in $apply results

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: V4.0_CS02
    • Fix Version/s: V4.0_CSD04
    • Component/s: Data Aggregation
    • Labels:
      None
    • Environment:

      Applied

    • Proposal:
      Hide

      ad 1.

      To comply with what we have decided in ODATA-945 (see red-lined document), the Forecast dynamic property must be placed at the top level of the result entities. Correct the response in example 61.

      ad 2.

      Remove "The introduced dynamic properties MUST always be in the same set as the original property.".

      To illustrate the rules, replace the request in example 64 with a variation of it:

      GET ~/Products?$apply=groupby((Name),
                         aggregate(Sales/Amount with sum as Total,
                                   Sales(Amount with average as AvgAmt)))

      Accordingly, move Total to the top-level entities in the result.

       

      Furthermore, the sentence in 3.1.1 Keyword as should read: "The introduced dynamic property is added to the context where the aggregate expression is applied to". This covers custom aggregates, which are also aggregate expressions.

      Show
      ad 1. To comply with what we have decided in ODATA-945 (see red-lined document ), the Forecast dynamic property must be placed at the top level of the result entities. Correct the response in example 61. ad 2. Remove "The introduced dynamic properties MUST always be in the same set as the original property.". To illustrate the rules, replace the request in example 64 with a variation of it: GET ~/Products?$apply=groupby((Name),                    aggregate(Sales/Amount with sum as Total,                              Sales(Amount with average as AvgAmt))) Accordingly, move Total to the top-level entities in the result.   Furthermore, the sentence in 3.1.1 Keyword as should read: "The introduced dynamic property is added to the context where the aggregate expression is applied to". This covers custom aggregates, which are also aggregate expressions.

      Description

      This problem occurs twice:

      1.

      The current text in 7.3 Custom Aggregates states that the dynamic property with the result of a custom aggregate “MUST always be in the same set as the original property.”

      Example 61 following this statement puts the result of the custom aggregate Forecast into the nested Sales structure although the request uses a path expression:

      GET ~/Products?$apply=groupby((Name), ... Sales/Forecast))

      2.

      The same statement appears in section 7.4 Aliasing. Here, it is not wrong, but may draw wrong conclusions , if it is applied to a variation of the request in example 64:

      GET ~/Products?$apply=groupby((Name),aggregate(Sales/Amount with sum as Total))

      Then, Total MUST be placed at the top result level.

       

      Furthermore, we should clarify this semantics in the sentence from 3.1.1 Keyword as: "The introduced dynamic property is added to the type containing the original expression or custom aggregate. "

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              gerald.krause1 Gerald Krause
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: