Open ChrisSchaller opened 4 years ago
@ChrisSchaller We don't believe that changing the constructor is the right approach here as the actions can only have body parameters. However, we do agree that we should support composing query options on top of actions or functions. We would be happy to review the changes if you are willing to contribute otherwise we will get this added to our backlog.
There is a lot of power in the server side in allowing Actions to accept
QueryOptions
, common scenarios include Create style actions that allow the result graph to be filtered or expanded, but also to allow customised filter experience for and endpoint that might have otherwise been implemented as a Function.But the client library does not facilitate passing through
UriOperationParameter
to action queries, even though the underlyingExecuteAsync
accepts an array of the base typeOperationParameter
.While it makes sense to restrict Function queries to only accept
UriOperationParameter
because the spec and many implementations support Query Options for Actions, the constructor forDataServiceActionQuery
should be relaxed to allowOperationParameter
.What would be more useful is if
DataServiceActionQuery
supportedAddQueryOption
.Assemblies affected
Microsoft.OData.Client 7.6.2
Expected result
DataServiceActionQuery
andDataServiceActionQuerySingle
should be able to accept bothBodyOperationParameter
andUriOperationParameter
:Actual result
Additional detail
With these simple changes to the constructor, it would be then easier to implement overrides, extensions or client generation to support
AddQueryOption
andExpand
support methods toDataServiceActionQuery
Originally the following syntax was expected to work:
The current work around involved editing the Uri in the
BeforeRequest
event handler to inject the additional query options: