Reputation: 62093
I seem to have an unusual need that I need to be able to $expand objects, but I can not do that using standard IQUeryable.
I am using EntityFramework and AutoMapper to project from database entities to API data objects that I then expose via OData. This has the problem that it limits what I can do - to those elements that AutoMapper can ProjectTo.
This generally is not a problem - if the items in the Api object are part of the database. I now have certain objects where I must (sometimes optionally) add data that comes from other sources. We talk generally about data only held in memory (like an object's error details, which include the stack trace, or some runtime stats).
As such, I need to find a way to manipulate (filter) queries and - more important actually - to handle $expand in single entity GET operations (though support for multi get is also welcome, but there I can possibly handle this by using ODataQueryDetails).
For single item queries, though, I have a controller method in the form like:
Get ([FromODataUri] Guid key) {
which gives me no access to the ODataQueryDetails at all. Anyone knows how to get those query details in this case?
Documentation on the whole "customize the query" element is not particularly big - and generally seems to assume someone is "Just playing with some IQueryable interface" - not taking into account that you may need a multi stage processing or do something that mixes in memory and database data.
Note: Web API OData: How do you $expand on a single entity? is NOT a duplicate - that was a single issue with a parameter name (key required as name) and does not go deep enough.
Upvotes: 0
Views: 651
Reputation: 2925
If you simply add a parameter to Get
as follows, Web API parameter binding will supply a value to the method. Let Thing
be the entity type handled by the controller.
public IHttpActionResult Get([FromODataUri] Guid key, ODataQueryOptions<Thing> opts)
Note that you need to specify the generic version of ODataQueryOptions
or you will get an exception.
This will get you an object representing the query options for the current request, but you will not be able to modify the options (none of the interesting properties have public setters). There seems to be a lot of developer demand for the ability to intercept and modify query options, but there is no out-of-the-box solution at the moment. See the open issue on Github that is currently targeting the 5.1.0 release. See OData V4 modify $filter on server side for current best practice on modifying query options in a controller method.
Upvotes: 1