Azure-Functions
Azure-Functions copied to clipboard
Azure
Support OData queries
Would love to see support for OData queries to functions, so that one could build an odata compliant service using Functions rather than an app service. OData supports .net core now, so the way to support this should be too far away. Today one might use parsers of the querystring but it doesn't work 100% of the time.
We would really benefit from this. We are looking at moving away from Azure functions due to the missing support for OData. But would rather not as we really like the Azure Functions.
I also was looking for this feature and would like if u guys supported it, i am unable to move 2 projects at this point to azure functions because of the lack of odata support.
I have a workaround while official support is being developed: https://github.com/aletc1/examples-odata-azure-functions,
Full details in: https://www.algohace.net/posts/odata-en-azure-functions-v2 (Spanish only)
We also wanna switch from Azure App Service to Azure Function. Would be great for our project too! Because we use OData in our Azure App Services we can't switch to Azure Functions.
We had a simple need, support GET requests with odata syntax. Thanks to the extension method provided by @aletc1 I was able to spend a few hours this afternoon and came up with a simple binding extension that has support for the EnableQuery attribute as shown here.
[EnableQuery(MaxTop = 100, AllowedQueryOptions = AllowedQueryOptions.Select | AllowedQueryOptions.Filter | AllowedQueryOptions.Top)]
[FunctionName("products")]
public static Task<IActionResult> Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)] HttpRequest req,
ODataQueryOptions<Product> odata,
ILogger log)
{
var data = new List<Product>
{
new Product { Sku = 1, Name = "Apple" },
new Product { Sku = 2, Name = "Lettuce" }
};
return Task.FromResult<IActionResult>(new OkObjectResult(odata.ApplyTo(data.AsQueryable())));
}
This would be super helpful for us to use in conjunction with Power BI rather than giving either raw database access or use an App Service 👍
Bear in mind that there's an open bug related to "select" clauses... https://github.com/OData/WebApi/issues/2118
Is there any workaround for v3?
@alexmartinezm -- I just pushed an update that makes this work for v3 Azure Functions
Great solution @smokedlinq Works just great! Are you going to publish as a Nuget package?
Not sure. I'm the furthest thing from an OData expert. I'm pretty sure I shouldn't publish it with the Microsoft prefix on the NuGet package if I do, so I'll first have to come up with a project name/code. ;p
@alexmartinezm @steven-pearson FYI I just moved this over to a new repo for my function extensions and published a nuget package AzureFunctions.Extensions.OData.
1+ Would be very nice to have official support for https://github.com/OData/aspnetcoreodata
This issue is 3 years old and is now onto its 3rd version of Azure Functions since the issue was raised. And still no OData implementation from Microsoft - only community workarounds.
How has this not been a priority? Does Microsoft feel that paging, sorting, and filtering of data is not important? Or that these features don't warrant an official framework solution?
Does anybody have any current workaround for Azure Functions v4; .Net6.0? This is bordering on being a deal-breaker for the platform as-is.
+1 please officially support this! without it, azure functions isn't working out to be a good option for api.
Tagging @fabiocav to see if this being considered in the new Isolated model
Please add this support, we are now unable to move to Functions V4 / .Net 6 as the community workaround has stopped supporting it.
https://github.com/smokedlinq-archive/Microsoft.Azure.WebJobs.Extensions.OData
Not ideal but consider creating an api and hosting it as a web app on azure.
Not ideal but consider creating an api and hosting it as a web app on azure.
Apologies, I'm not sure if I understand what you are suggesting.
If you mean to avoid functions altogether and revert to the "old way" of doing things (.Net Core WebApis hosted as AppServices) - this is essentially the decision I have made in those instances where OData is required (which is almost every project). It's simply not practical to create a custom data fetching solution - this problem was solved years ago. Microsoft took three steps backwards on this with Functions and has remained there, giving zero indication as to whether they are even considering implementation of a basic feature.
For all the promise of serverless computing; Microsoft has not really been at the top of the game by a fair margin. Just as one small example of questionable priority decisions; Microsoft recently added Swagger/OpenAPI to Functions. And while I am all for this - there is no way this was more needed than formal OData support. OpenAPI is a nice to have while OData is a need.
Not ideal but consider creating an api and hosting it as a web app on azure.
Apologies, I'm not sure if I understand what you are suggesting.
If you mean to avoid functions altogether and revert to the "old way" of doing things (.Net Core WebApis hosted as AppServices) - this is essentially the decision I have made in those instances where OData is required (which is almost every project). It's simply not practical to create a custom data fetching solution - this problem was solved years ago. Microsoft took three steps backwards on this with Functions and has remained there, giving zero indication as to whether they are even considering implementation of a basic feature.
For all the promise of serverless computing; Microsoft has not really been at the top of the game by a fair margin. Just as one small example of questionable priority decisions; Microsoft recently added Swagger/OpenAPI to Functions. And while I am all for this - there is no way this was more needed than formal OData support. OpenAPI is a nice to have while OData is a need.
Right that's why I said it is not ideal but given that microsoft has not addressed the issue for 3 years it's a possible solution.
I love so much of what Functions represents, but then issues like this come up and remain unaddressed for years. These are things that prevent Functions from being an option for many users and businesses.
Another vote for this please. I have a need for a simple GET endpoint to fetch data from an EFCore data store. This is relatively simple to achieve in ASP.NET Core WebApi, but I really need the scalability, flexibility and lower overheads/maintenance of an Azure Function.
Bumping the thread. This is a very nice feature that is BROKEN. Evidently it used to work. Are new features > broken old features?
