techniq
commented
5 years ago Update on the 2 checkboxes above
Passing function parameters
Reading the OData spec regarding Complex and Collection Literals:
Complex literals and collection literals in URLs are represented as JSON objects and arrays according to the arrayOrObject rule in [OData-ABNF]. Such literals MUST NOT appear in the path portion of the URL but can be passed to bound functions and function imports in path segments by using parameter aliases.
Since these values can always be treated as JSON (either a JSON array or JSON string, etc), I was able to handle the list of strings mentioned above using:
[HttpGet("WithRoles(roleCodes={roleCodes})")]
public IActionResult WithRoles(string roleCodes = "")
{
var roleCodesAsArray = JArray.Parse(roleCodes).ToObject<IEnumerable<string>>();
// ...
}when passed as a JSON-escaped string (ex. SomeFunc(someProp='test')) I can handle it using:
[HttpGet("SomeFunc(someProp={someProp})")]
public virtual IActionResult SomeFunc(string someProp)
{
var parsedValue = JValue.Parse(someProp).Value<string>();
// ...
}There is supposedly a performance difference between .Value() and .ToObject() but I haven't verified myself (or seen a multi-second response).
I haven't tested if this will handle an collection parameters with a complex type (which is then aliased). See this odata-query test for an example, but basically passing [{foo: 1, bar: 2}] as a parameter. I guess something like this might work (rather ugly though).
[HttpGet("SomeFunc(someProp=@someProp)?@someProp={someProp}")]
public virtual IActionResult SomeFunc(string someProp)
{
var parsedValue = JArray.Parse(roleCodes).ToObject<IEnumerable<string>>();
// ...
}Not sure how it would work when also passing OData query via the query string as well. For example:
http://localhost:5000/SomeFunc(someProp=@someProp)?@someProp=[{foo: 1, bar: 2}]&$filter=Name eq 'Test'I also came across AspNetCoreJTokenModelBinder which appears to allow you to bind to a JToken (still need to call .ToObject<...>() on a JArray or Value<...>() on a JValue but might be useful instead of taking in a string and parsing directly. The implementation seemed to be doing a good bit more though
Resolve issue when calling parser.ExecuteReader(query)
This is still a big issue for me and not sure I can find a way to work around it. Hoping you have a good idea :).
One thought was to register the function in the EdmModel we could expose:
[ODataFunction("WithRoles(roleCodes={roleCodes})")]
public IActionResult WithRoles(string roleCodes = "")
{
// ...
}or
[ODataAction("WithRoles(roleCodes={roleCodes})")]
public IActionResult WithRoles(string roleCodes = "")
{
// ...
}depending on the use case (Actions can have side effects (typically HttpPost) and Functions can not (typically HttpGet), but might need to also also attribute accordingly. See spec.
Anyways, just being able to take an OData query string and apply it anymore is really my use case (including applying to OData query to a custom Queryable, see WithRoles example in the original comment above.
voronov-maxim
Currently with OData/WebApi I am able to register an OData function in the EdmModel...
..and then expose it in the Controller
I can then call it using
where you pass the function parameters via
(roleCodes=['Foo','Bar','Baz'])as well as process the OData query string$select,$top, etc.I attempted something similar using pure ASP.NET Core routing and ODataToEntity...
...but am running into the following issues
roleCodesparam as an array (ex.WithRoles(roleCodes=['Foo','Bar','Baz']))parser.ExecuteReader<User>(query)callI think to support this use case, the following needs to be supported:
odata-querytests.FromODataUri):/products?sizes=s,m,land not/products(sizes=['s','m','l'])parser.ExecuteReader<User>(query)EdmModellike in OData/WebApi (although this isn't the case with stored procedures in ODataToEntity, so I dunno).