Ian Bennett
My feedback
-
265 votes
Upvotes: 8
<=-=Mar 5 2017 2:42PM=-=>Thanks for this idea. This is a valid requirement and I hope that it will get more votes. Currently we cannot confirm when it will be added, but it is in our backlog.
<=-=May 22 2017 5:03AM=-=>would like it very much, particularly since you already have the CONCAT / GREATEST() a variable number of paramenters and does something with it…
<=-=Jun 5 2017 12:31PM=-=>GREATEST / LEAST functions would be fantastic addition.
<=-=Nov 14 2017 3:42PM=-=>The workarounds using CROSS APPLY or CASE expressions are difficult to manage and read. I’d love to see these implemented.
Ian Bennett
supported this idea
·
-
37 votes
Thanks for the feedback, keep votes coming!
Ian Bennett
supported this idea
·
-
125 votesIan Bennett
supported this idea
·
-
47 votesIan Bennett
shared this idea
·
-
3 votesIan Bennett
supported this idea
·
-
49 votes
Have you considered using a lambda architecture in Cosmos DB?
This is a very typical pattern for IOT and Cosmos DB. Feel free to take a look here but I think you can get precisely what you want using Cosmos DB with Change Feed and Spark.
https://docs.microsoft.com/en-us/azure/cosmos-db/lambda-architecture
Thanks.
Ian Bennett
commented
In regards to the Lambda Architecture, that is sort of what I have done but more simply and cheaper by just creating a second Cosmos collection with a TTL setting of a few days only. I write to this and the long term collection simultaneously. Using database level RU allocation I can efficiently utilise RU between the short term collection which is mainly queried adhoc during the day and the long term collection which is mainly queried in batch overnight.
Ian Bennett
commented
My partition keys are GUIDs in order to evenly distribute eclectic data over the partitions. I therefore do not know the keys upfront and "DISTINCT partitionKey" is of no use.
Ian Bennett
commented
Also, it looks like the node.js SDK does not support passing of partition keys when executing a stored procedure.
Ian Bennett
shared this idea
·
-
89 votes
Hi Ibrahim,
What issue are you trying to solve? What use case would this be used for?
It seems to me that placing a restart option on the plan level might do more harm than good, by resetting the memory on all the apps under the plan. Depending on your scenario, auto-heal would be a great solution to solve individual machine issues. See a video by my colleagues here for more details: https://channel9.msdn.com/Series/Windows-Azure-Web-Sites-Tutorials/Auto-Healing-an-Azure-App-Service
Placing this idea under review for now until I understand what’s at the base of the request here.
Thanks!
OdedIan Bennett
supported this idea
·
Ian Bennett
commented
There are some services that appear to be App Service Plan based and if broken, cannot be resolved by restarting at the App Service level. For example, MSI (Identity) which was apparently a VM plugin (there appears to have been major changes to MSI so not sure if this is still the case). Also I am having problems with Always On across all of my App Services (i.e. it has stopped working) so I suspect this may be another case.
-
5 votesIan Bennett
commented
Agree that there needs to be some way to organise related Logic Apps. I have to use 3 Logic Apps just for overnight scheduling of lights at one site (1 to turn lights on, 1 to dim at a later time, 1 to turn off). If I am to roll this out in ernest I would likely end up with thousands of Logic Apps which will be a nightmare to manage, so am having to look at other solutions.
Ian Bennett
supported this idea
·
-
2 votesIan Bennett
shared this idea
·
-
4 votesIan Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
7,845 votes
We are looking at options to enable this.
Ian Bennett
supported this idea
·
-
1 voteIan Bennett
shared this idea
·
-
638 votes
Update:
Bytecode support for Gremlin API is scheduled for public preview, December 2019.
Thanks.
Ian Bennett
supported this idea
·
-
2 votes
@Ian.
With regards to secondary regions having different RU/s we do not have this on our road map at this time. There is another User Voice items which have this suggestion, Please feel free to vote that item up.
@Nick.
For scenario 1. Same answer.
For scenario 2. Typically, just putting the front-end closer to users is not something we see help with application latency where they are backed by a database as the app still needs to call the database which is still separated by some distance.
With regards to knowing which region to point to I would suggest conducting tests to see which regions provide the best latency and include this as the preferred regions for each regional deployment.
Thank you both for your suggestion and comments.
Ian Bennett
commented
The replica is setup more for DR purposes but there is no option to run the secondary at reduced RUs so that is potentially a lot of wasted resource and money. If I am using something like Power BI Service then I don't get a lot of say in where the application runs from. You are assuming a 3 Tier Architecture but Cosmos is not just being used for apps and websites. Data Analytics applications are often 2 Tier and more taxing on the database.
Ian Bennett
shared this idea
·
-
14 votes
This capability is not on our road map today but we do provide query metrics using our SDK’s. You can read more about what we provide here, https://docs.microsoft.com/azure/cosmos-db/sql-api-sql-query-metrics#query-execution-metrics.
Thank you for your suggestion.
Ian Bennett
commented
By "monitor" I mean individual queries and the focus on this suggestion was actually meant to be on the "killing" part. Its not hard to end up with rogue queries chewing up the RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
22 votesIan Bennett
commented
A trigger based on "Number of requests exceeded capacity" metric would be useful too. Logic flow might look something like if number of requests exceeds capacity > n then increase RU throughput by 10% with a maximum of x RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
@Andrew, OAuth is fine if you don't want to provide any user functionality such as per API security, self-service, per user monitoring etc. To do that, you have to either pay a fortune or get your internal users to sign up with personal microsoft accounts which is a bit tacky.