Azure Cosmos DB
Have feedback for Azure Cosmos DB product? Submit your idea here or upvote other ideas. All feedback is monitored and reviewed by the Azure Cosmos DB team.
This site is for feature suggestions only. For technical questions or issues, please submit them to StackOverflow,where we and the community can better help you.
Please use the following categories when submitting your idea.
Gremlin API: Graph features and capabilities using Gremlin API.
MongoDB API: Features and capabilities using MongoDB API.
Table API: Features and capabilities using Table API.
Etcd API: Features related to using etcd as a configuration store for Kubernetes.
Built-in Apache Spark: Features related to built-in Apache Spark in Azure Cosmos DB.
Built-in Notebooks: Features related to built-in Notebooks in Azure Cosmos DB.
SDK: Features related to Azure Cosmos DB SDKs for SQL API.
Change Feed: Features related to Change Feed.
Management: All management features, backup/restore,monitoring, ARM, PowerShell and CLI.
Portal: All features for Azure Portal and Cosmos DB Explorer.
Emulator: Features related to the Azure Cosmos Emulator.
Other: Features not related to any other category.
-
Gremlin bulk executor for python library
Will the bulk executor be available for python?
such as bulk (create / update / delete) vertices and edges11 votesThanks for your suggestion. We have reviewed this but at this time have no plans for this. Will add to our backlog and revisit in future cycles.
Thanks.
-
[Gremlin] Paging Support
Please add paging support for Cosmos Graph DB via the Gremlin API. Traversing the whole graph for a large set of vertices can be very expensive. Paging would allow better efficiency when targeting a subset of a large set of vertices.
40 votes -
Make intrinsic properties of edges indexed.
Are there any plans to make the intrinsic properties on edges indexed
See context/performance implications here:
https://github.com/MicrosoftDocs/azure-docs/issues/49946EDIT: Noticed I messed up the title, it should be fixed now.
3 votes -
Use a domain ontology (RDF/OWL) as a scheme in Graph DB?
In Cosmos Graph DB, I would like to be able to import a domain ontology (RDF/OWL) as a scheme to model data.
23 votesThanks Marc for your suggestion. This would require onboarding an entirely new API and is not currently on our roadmap.
Marking as unplanned.
Thanks!
-
To be upto date version of TinkerPop in Azure Cosmos Graph DB
Apache TinkerPop Graph released v3.4.2 on 28th May 2019, but it seems that Azure Cosmos DB graph is still supporting the v3.2 which was released a year back from today. Azure Cosmos Graph DB should be upto date to support the latest version of Apache TinkerPop Graph.
TinkerPop v3.4 supports various features like having support of min and max operations on comparable like string.
21 votesHello and thanks for your request. We support 3.4 from a driver and connectivity perspective but there are a number of features we haven’t implemented such as min and max on non-decimal values.
These are currently on our backlog to implement so will mark this as unplanned for now which will keep this request open. When this moves off of our backlog we will mark this as planned and update you here.
Thank you.
-
Support Gremlin Bytecode to enable the fluent API of Gremlin.NET
Azure Cosmos DB Graph API doesn't support Gremlin Bytecode. Therefor it is not possible to use the fluent traversal API of Gremlin.NET.
Within the Azure Cosmos DB Graph .NET API (https://docs.microsoft.com/en-us/azure/cosmos-db/graph-sdk-dotnet) it is recommended to use Gremlin.NET. So it would be really nice if all features of Gremlin.NET would be supported.
See also the idea of a "better type-safe APIs fro Gremlin" (https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/19340761-better-type-safe-apis-for-gremlin) within the Graph API feedback.
768 votesUpdate on this item.
Bytecode implementation is now targeting the first half of 2020 to provide stability and performance improvements in the platform.
Apologies for the delay. We are continuing to work on this. Will announce here when this becomes available.
Thanks.
-
DATA QUALITY: Please allow for properties to be set using a subquery
The use case here is incrementing the reply count property on a post vertex. To increment, we have to fetch the post vertex, increment the reply count property within our API, then update the graph with the new property value. Unfortunately, if multiple users reply simultaneously using different instances of our API, the reply count value is set incorrectly. Sending a query to the database and letting the server make the updates by calculating the value would address the issue.
6 votesThank you for your suggestion.
At this time we are still investigating and evaluating this type of capability. This is on our backlog and we will continue to evaluate this with additional customer input. We will update this as this progresses.
Thanks.
-
Tail() Gremlin step support
Create an empty graph and add the following with partition as a.
g.addV('person').property('a','1').property('name','person 1').property('number',1)
g.addV('person').property('a','1').property('name','person 2').property('number',2)
g.addV('person').property('a','1').property('name','person 3').property('number',3)Then run the following:
g.V().order().by('number')
returns: person 1, person 2, person 3
g.V().order().by('number').tail(1)
returns: person 1This is not expected result as it should return person 3. But when the property is used to run the same thing or use the query with fold()/unfold() before .tail()
g.V().order().by('number').properties('name')
returns: person 1, person 2, person 3
g.V().order().by('number').properties('name').tail(1)
returns: person 31 vote -
Integrate existing Janus GraphDB application with Azure Cosmos DB API for Gremlin and Open Service Broker for Azure
I read a post on how to Integrate existing MongoDB application with Azure Cosmos DB API for MongoDB and Open Service Broker for Azure, https://docs.microsoft.com/en-us/azure/aks/use-cosmosdb-osba-mongo-app, and I start to think is it possible same technique could be adopt to janus graph->COSMOSDB graph?
4 votes -
Partition keys should propagate to newly created vertices
Assume a pre-existing graph whose vertices are on different partitions (and thus have different partition keys).
Now, consider adding new vertices through new edges in bulk through the Gremlin API, e.g. like this:
g.V().addE('l').to(__.addV('newVertex').property('PartitionKey', 'p')
This would work just fine but it would possibly place the source and sink vertices into different partitions. If we would want them to remain on the same partition, we're currently lost with CosmosDB.
The Tinkerpop API allows the property-step to specify a traversal, so the following query is actually possible in the Tinkerpop reference implementation and would solve the issue:
g.V().as('source').addE('l').to(.addV('newVertex').property('PartitionKey', .select('source').id())
This…
2 votes -
DATA QUALITY: Please support graph transactions.
Today, if a traversal fails at step n of m, figuring out what state the graph is in is quite a chore. As a result, all data modification traversals have to be written to support retries. Unfortunately, if the retrying component fails, the network fails, or something else fails, which prevents retry, the graph is left in an unknown state.
2 votesHello and thank you for your suggestion.
While Cosmos DB provides support for transactions within a partition, we do not have support multi-step, cross-partition or distributed transactions.
We recommend to customers requiring transactions across multi-step operations to coordinate these using the consistency model and optimistic concurrency control.
Thank you for your suggestion.
-
Please add the none step.
When we create or update vertices and edges, we don't need the results from the traversal. Having the results filtered out server-side saves resources.
3 votesThank you for your suggestion. We will review this and update at a later time.
Thanks.
-
Allow shortestPath and sum steps
I want to make traversals finding the shortest path between one or more vertices. I need to be able to use shortestPath step or at least have sum step to sum up the edge weights to accomplish this.
12 votesAt this time this feature is not on our road map. We will leave this marked as unplanned for now and will revisit this in upcoming cycles and will update here if this changes.
Thank you for your suggestion and votes.
-
Improve range() step costs
Graph API is nice, however in its current state it is unusable for large data sets due to high RU costs.
We are trying to implement paging for retrieving large amounts of data, however RU cost is unacceptable. Query "g.V().range(0,100)" costs 63.11 RU, however "g.V().range(2000,2100)" costs 338.06 RU even though it is same amount of data. Higher values are even more expensive meaning it's impossible to retrieve high amount of data without scaling up throughput.39 votesWork for this feature has been started. Will update here when this feature becomes generally available.
Thank you.
-
within predicate
Please add support for the 'within' predicate. https://tinkerpop.apache.org/docs/3.3.2/reference/#where-step
1 vote -
Microsoft join and support GQL
I think it would be a great benefit for Cosmos DB to support the new movement to get to a single Graph Query Language. Microsoft joining this movement might help in rapid evolution and acceptance of such a language.
Taken from https://neo4j.com/blog/time-for-single-property-graph-query-language/:
The time has come to create a single, unified property graph query language.
Different languages for different products help no one. We’ve heard from the graph community that a common query language would be powerful: more developers with transferable expertise; portable queries; solutions that leverage multiple graph options; and less vendor lock-in.
One language, one skill set.
…
84 votesSupport for this is not on our roadmap but will mark as unplanned and leave open for future consideration.
Thank you for your suggestion.
-
Support multi-properties in GraphBulkExecutor.
Gremlin API, supports:
Multiple properties (multi-properties): a vertex(edge) property key can have multiple values. For example, a vertex can have multiple "name" properties.Properties on properties (meta-properties): a vertex(edge) property can have properties (i.e. a vertex property can have key/value data associated with it).
So, now it's impossible to upload data with such properties with GraphBulkExecutor.
6 votesAt this time this feature is not on our road map. We will leave this marked as unplanned for now and will revisit this in upcoming cycles and will update here if this changes.
Thank you for your suggestion and votes.
-
CosmosDB Graph API should support array types inside Gremlin properties
Currently, the CosmosDB Graph API does not support array types inside of Gremlin properties. This forces users to rebuild their graph models to match what the Graph API requires. The CosmosDB Graph API should support array types inside of Gremlin properties.
34 votesWe’ve evaluated this request and at this time we are deferring this from our road map. Will leave this as open so we can consider this in the future.
Thanks.
-
Gremlin Graph: Add support for array values in group() and groupCount()
You should be able to group by an array of values. it is perfectly valid to do a group() or groupCount() like so:
g.V().groupCount().by(values('id','name').fold())
Other Graphs implementing Gremlin will give you a result, while CosmosDB fails with:
"Unexpected Error: Cannot resolve object to a primitive value."
13 votesWe have reviewed this request and at this time this is not on our road map.
Will leave this open and review this in upcoming cycles for our road map.
Thanks.
-
Add support for sack
Currently GraphAPI has almost no support for doing operations while traversing or listing vertices, like combining vertex properties with weights (edge property) as you traverse. Math is not supported, and often times an alternative would be to use a sack, but that is also not supported. So there is really no workaround.
10 votesThank you for your suggestion. We have reviewed this request and at this time this is not on our road map. Will leave this marked as open so we can revisit this in future planning cycles.
Thanks.
- Don't see your idea?