JeffC
My feedback
-
1,026 votes
Thank you for the feedback, we are reviewing this feature request.
An error occurred while saving the comment An error occurred while saving the comment JeffC
commented
This is holding up several projects to move from rest to grpc. (Because we require rest fallback for some older consumers)
JeffC
supported this idea
·
-
26 votes
Upvotes: 43
An error occurred while saving the comment JeffC
commented
AT TIME ZONE is slow enough that I just avoid it and use .NET TimeZoneInfo methods to convert at the client application.
If SQL could deliver the performance at least equal to client applications using TimeZoneInfo I'd be included to use it frequently.
JeffC
supported this idea
·
-
9 votes
Upvotes: 2
JeffC
supported this idea
·
-
166 votes
Need feedback if what we announced with this blog post is not what was asked for.
https://devblogs.microsoft.com/cosmosdb/new-date-and-time-system-functions/
An error occurred while saving the comment JeffC
commented
This would be extremely helpful. We have to use DateTimeOffset for proper date handling and display throughout our application and SQL Server does it quite well. But I want to move part of our application over to Cosmos DB and can't do it until there is support for DTO.
JeffC
supported this idea
·
-
65 votes
Leaving as started becasue we don’t have full docs out yet but this is completed. Just need to document and provide samples
JeffC
supported this idea
·
An error occurred while saving the comment JeffC
commented
I can see how this would be useful in some situations. I guess you'd have to have a setting for the max number of items to fetch from SB. Then your main function method (Run) would need to have the arguments expect a list of message objects.
-
103 votes
This is currently on our radar and is now planned work. Thanks for voting!
- Cary, Azure Functions
JeffC
supported this idea
·
An error occurred while saving the comment JeffC
commented
For sure Azure SQL. We're using Service Bus as a go between now but it would be better to have a SQL trigger.
-
88 votes
Here’s the latest as there seem to be 2 types of ask here and so two seperate updates. Need comments for if this issue should close to be focused on one or other:
1. I want to control how many calls my function can make to another API (the 3rd party API rate limiting).
– In all plans we now have a way to specify the max instances. This can limit how far a function app instance can scale: https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#limit-scale-out2. I want to stop my function from triggering more than x times an hour.
Nothing planned in this in the short term. Using API Management for HTTP functions with throttles would be our recommendation for HTTP, nothing out of box for non-HTTP triggers yet.JeffC
supported this idea
·
An error occurred while saving the comment JeffC
commented
I'd like to have this ability to protect our functions from misuse.
-
16 votesJeffC
shared this idea
·
-
245 votes
An error occurred while saving the comment JeffC
commented
This is the #1 missing feature that prevents me from going live with Azure Scheduler. I have jobs that need to run at specific local times across timezones all around the world.
Examples: job1 run at 3am PST Los Angeles, job2 run at 3am EST New York, job3 run 3am IST Dublin.
For a scheduler to work for our needs there must be the ability to schedule the job to run in a specific timezone and then the scheduler must account for daylight savings time to be sure the job always runs at the correct local time.
We are using a home grown scheduler that is short on features and I'd like to leave it to run on Azure but timezone and DST support is a showstopper for us. Our homegrown system has been able to handle this for years. A few lines of C# can handle the conversion between future job schedule time and UTC and will account for what the target timezone DST offset will be (if any) at the scheduled date and time.
Unfortunately we've already had to skip on gRPC for a project because it won't run on Azure App Service.
And there's another where the owners are considering now not using Azure App Service because they really want gRPC.
I'll probably be facing more of these opportunities next year. I'm hoping that there will be progress on this at some point in the near future.