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

Strengthen definitions for $orderby, $top and $skip

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: V4.01_OS
    • Fix Version/s: V4.01_ERRATA01
    • Component/s: Protocol
    • Labels:
      None
    • Proposal:
      Hide

      Aligned with the wording in OData-Data-Aggregation-Ext-4.0:

      11.2.6.3. Let A be a copy of the result set with a total order that extends any existing order of the result set but is otherwise chosen by the service. The total order MUST be stable across requests.

      If A contains more than n instances, the result of $top=n consists of the first n occurrences in A. Otherwise, the output set equals A. The instances in the result are in the same order as they occur in A.

      11.2.6.4. Let A be a copy of the result set with a total order that extends any existing order of the result set but is otherwise chosen by the service. The total order MUST be stable across requests.

      $skip=n excludes from the result set the first n occurrences in A. It keeps all remaining instances in the same order as they occur in A.

      Somewhere in 11.2.6. The order of the result MUST be respected during serialization to the response payload.

      Show
      Aligned with the wording in OData-Data-Aggregation-Ext-4.0 : 11.2.6.3. Let A be a copy of the result set with a total order that extends any existing order of the result set but is otherwise chosen by the service. The total order MUST be stable across requests. If A contains more than n instances, the result of $top=n  consists of the first n occurrences in A. Otherwise, the output set equals A. The instances in the result are in the same order as they occur in A. 11.2.6.4. Let A be a copy of the result set with a total order that extends any existing order of the result set but is otherwise chosen by the service. The total order MUST be stable across requests. $skip=n  excludes from the result set the first n occurrences in A. It keeps all remaining instances in the same order as they occur in A. Somewhere in 11.2.6. The order of the result MUST be respected during serialization to the response payload.
    • Resolution:
      Show
      https://github.com/oasis-tcs/odata-specs/pull/173

      Description

      Total or partial order?

      OData-Protocol, section 11.2.6.2 speaks of "the order" in which items are returned. Must this be a total order, or only a partial order? A partial order would not allow paging with $top and $skip. But not all services may be able to produce a total order.

      This should be clarified.

      Further implications of partial ordering

      OData-Protocol, section 11.2.6.3 seems to allow n arbitrary items to be returned:

      a non-negative integer n that limits the number of items returned from a collection.

      The next sentence sounds as if a number was returned:

      The service returns the number of available items up to but not greater than the specified value n.

      OData-Protocol, section 11.2.6.4 is clearer:

      excludes the first n items of the queried collection from the result. The service returns items starting at position n+1.

      Both definitions assume that "the first n items" always exist. But in general the result set is neither totally ordered (in which case "the first n" would be well-defined) nor totally unordered (in which case n arbitrary items could be returned or skipped). After an $orderby, the result set may be only partially ordered.

      The definitions of $top and $skip should make clearer what freedom to choose n items the server has.

        Attachments

          Activity

            People

            • Assignee:
              heiko.theissen Heiko Theissen
              Reporter:
              heiko.theissen Heiko Theissen
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: