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

Clarify whether query options can be applied to the result of an action invocation.

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: ABNF, Protocol, URL Conventions
    • Labels:
      None
    • Environment:

      Proposed

    • Proposal:
      Hide

      Clarify that query options, such as filter, orderby, may be supported.

      Be clear that following nextLinks should NOT cause side-affects.

      Warn that $top/$skip, if supported, should not be used to invoke client paging through the results of an action that may be side-affecting.

      Show
      Clarify that query options, such as filter, orderby, may be supported. Be clear that following nextLinks should NOT cause side-affects. Warn that $top/$skip, if supported, should not be used to invoke client paging through the results of an action that may be side-affecting.

      Description

      Originally, actions were intended to map to sql stored procedures and functions to user defined functions. Sql stored procedures are (possibly) side-effecting and not guaranteed to be idempotent, so are not safe for a query processor to compose with other query operators. As such, stored procedures don't support composition, filtering, ordering, etc., where user defined functions do.

      So, functions have an `IsComposable` attribute to specify whether they can be followed in a resource path with additional segments and query options, where actions do not have such an attribute and are defined not to be composable (though we never actually define composable, and whether it only applies to composition in the resource path or whether it precludes things like $orderby/$filter).

      OData quickly grew beyond the databases, and we relaxed many of the implication constraints imposed by underlying storage systems such as sql.

      There is nothing in the text or ABNF to explicitly preclude the use of query options, including $filter and $orderby, from being applied to the results of an action. I think that was intentional, but I don't see it explicitly called out anywhere.

      The ABNF does preclude appending any segment to a bound action invocation, including the use of /$query for action invocations, but doesn't seem to preclude query options such as ?$filter.

      In ODATA-569, we decided to explicitly allow appending a cast segment to the result of an action, which is performing a special type of filtering operation, further suggesting that such post processing should be supported for actions. However, that doesn't seem to be reflected in the ABNF.

      Further, we do not preclude nextLinks from the results of actions, nor warn that following a nextlink should not cause a side-affecting action to be re-invoked, especially if it is not idempotent (though that could be implied by the use of GET).

      So, while it's clear that actions don't support appending certain segments (i.e., you can't navigate to related entities) it is suggested that some segments (like cast segments) were intended to be supported, and very murky what query options should be supported.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mikep Michael Pizzo
            • Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: