JeffC
My feedback
-
18 votes
Upvotes: 43
An error occurred while saving the comment JeffC
supported this idea
·
-
6 votes
Upvotes: 2
JeffC
supported this idea
·
-
155 votes
Work on this feature is now started. Will update when this is released.
Thanks.
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
·
-
61 votes
This is now available in the latest Service Bus trigger version: https://github.com/Azure/azure-functions-servicebus-extension/issues/15
Just tracking another issue to ensure can be leveraged outside of .NET https://github.com/Azure/azure-functions-servicebus-extension/issues/65
-
JeffJeffC
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.
-
91 votes
This continues to be unplanned. Please keep the votes coming! – Matthew
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.
-
85 votes
Moving this work item to unplanned, as it is clear that this request is no for a global throughput limit.
We do now offer the ability to limit your maximum instances in the Premium plan, which will allow you to avoid swamping downstream resources. https://docs.microsoft.com/en-us/azure/azure-functions/functions-premium-plan#plan-and-sku-settings
We prioritized that above a max call per X limit, because our only control to limit throughput is to outright deny some number of requests above a threshold.
Keep the feedback coming!
Alex
Azure Functions TeamJeffC
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
·
-
240 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.
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.