Access a property of the result of a non-composable function

[ralfhandl]

Must a function be composable to allow access to individual properties of its returned value?

GET BillingDocument('90000090')/self.GetPDF()/BillingDocOutputDataBinary

The CSDL specification says

A composable function can be invoked with additional path segments or key predicates appended to the resource path that identifies the composable function, and with system query options as appropriate for the type returned by the composable function.

and BillingDocOutputDataBinary is an "additional path segment".

The Protocol specification seems to allow system query options without composability

If the function is composable, additional path segments may be appended to the URL that identifies the composable function (or function import) as appropriate for the type returned by the function (or function import). The last path segment determines the system query options and HTTP verbs that can be used with this this URL

Assuming that BillingDocOutputDataBinary is a stream property,

GET BillingDocument('90000090')/self.GetPDF()?$expand=BillingDocOutputDataBinary

is allowed without composability, and it requires the server to retrieve the same data (just serialize it differently).

Related to ODATA-1644

Proposal

Step 1: come up with one definition of non/composability, also taking actions into account which are "non-composable" now

Step 2: complement it with capabilities to express what actually is possible if a function is "composable"

Imported from ODATA-1640

[ralfhandl]

Discussion in TC 2024-03-20

Discussion:
Mike noted that we need to clarify the definition of 'composable'.

• https://en.wikipedia.org/wiki/Composability
• https://en.wikipedia.org/wiki/Function_composition

Need to clarify the intention of the non-composable requirement.
Ralf notes:

• $select seems easy.
• $expand seems hard.
• $filter can be easy or hard.
• Following a property seems easy.
• Following a navigation property seems doable.

After defining composable, open issue is whether to document cautions on the use of this feature. Additionally, do we standardize ability of server to say it can or will not perform the query? And, how to advertise the likelihood that a server will perform a query.

The solution should also consider Actions as well as non-composable Functions.

[mikepizzo]

The original composability requirements have their origins in SQL -- the idea was that an action could be mapped to a stored procedure, which is not composable and could have side-affects, while a function could be mapped to a user defined function, which is composable and does not have side-affects.

The root of this is the fact that, to be composable, a query processor may need to execute the request multiple times and, which could be problematic if the request was side-affecting.

For functions, I think "non-composability" was added because the implementation of the function may be "passthrough" -- i.e., I may be calling an HTTP GET under the covers to get the data, and I have no way to push down any additional query expression.

[ralfhandl]

Non-composable: don't add path segments or query options.

Composable: may add path segments or query options, and may use different HTTP verbs with the elongated paths.

Adjust text in both specs accordingly, and synchronize the texts.

[mikepizzo]

Actually, the protocol doc doesn't say anything about non-composable functions supporting query options. Upon closer reading, the cited text is really making the point that the end segment determines the HTTP verb (and query options), lest there be any confusion (since we generally say that functions are requested using GET but, as per the example, it may be invoked through a POST, for example, if the ending segment represents an action, or a collection to which we are adding a member.