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 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.
-
Implement LIKE keyword
Add support for the LIKE '%%' SQL keyword and associated functionality.
824 votesAzure Cosmos DB supports the CONTAINS, STARTSWITH, and ENDSWITH built-in functions which are equivalent to LIKE.
We are planning to add support for LIKE since this is a top requested item, but meanwhile, please use the other equivalent keywords.
-
Support Document Versioning
The ability to generate links to a previous version of a document would be a powerful addition DocumentDB that has many use cases.
In my case I need a self managed profile document that needs to be referenced at point in time to be tied to an event.
776 votesAzure Cosmos DB now provides the ability to access the change feed (https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed). A common pattern to implement eventing patterns is
1. Store every version/change as a separate item
2. Read the change feed to merge/consolidate changes and trigger appropriate actions downstream.You can also expire old versions using TTL: https://docs.microsoft.com/en-us/azure/cosmos-db/time-to-live
-
Add the ability to delete ALL data in a partition
In a partitioned collection, it would be useful to have the option delete all data with a given partitionId.
545 votesWork on this item has started. Will update as this progresses.
Thank you.
-
Add support for single entity retrieval instead of IEnumarable
Single \ First and so are currently not supported in Document DB
For example, the following code:
return client.CreateDocumentQuery<TEntity>(collection.SelfLink).SingleOrDefault(x => x.Id == id);
causes the error:
An exception of type 'Microsoft.Azure.Documents.Linq.DocumentQueryException' occurred in Microsoft.Azure.Documents.Client.dll but was not handled in user code
Additional information: Query expression is invalid, expression return type Entities.Models.Hierarchy is unsupported. Query must evaluate to IEnumerable.
502 votesThank you for your feedback. I have discussed this in more detail with our team.
You are correct the workaround suggested to use .AsEnumerable().FirstOrDefault(). should not be a recommended work around. This way results in materializing all documents on the client first before getting the 1st document, which is not very efficient and the exact opposite of what you are trying to achieve.
Instead we recommend you use Take(1).AsEnumerable() and then .First() or .Single() or .FirstOrDefault() for Single() and First(). Take(1) is translated to SELECT TOP 1 and is processed server-side so more efficient than the previous suggestion and is what you are trying to achieve.
As to the original ask. The support for these operations can be done, but this work is not prioritized against the other work we want to deliver. I will move this back as unplanned but please note this is on our roadmap.
Thanks again…
-
Linq provider should respect JsonSerializerSettings ContractResolvers
JsonSerializerSettings are now supported when creating the client, as per https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6422364-allow-me-to-set-jsonserializersettings
However, when using for example a CamelCasePropertyNamesContractResolver to store the data, the linq queries will fail if the properties on the POCO classes are Pascal case.
460 votesThis is currently not on our roadmap. However, we will continue to review this item in the future as we prioritize future releases.
Thank you for your suggestion.
-
Support ORDER BY on the ST_DISTANCE spatial function
Ordering results by the ST_DISTANCE spatial function is currently not supported.
414 votesThis item was incorrectly marked as started. Actual work on this item has been deferred but is still planned.
Will update when this work is started.
Thank you.
-
Support case insensitive indexing
Order by returns lowercase characters before uppercase characters.
x
y
z
A
B
CI know you can work around this by storing an all lower or all upper case version of the string you want to query by on your object but over time and scale that does add to your RU usage
199 votesWork on this has been started.
Will update when complete.
-
Add DateTimeOffset support
The DocumentDb engine should be able to recognize and properly order DateTimeOffset serialized fields.
155 votesWork on this feature is now started. Will update when this is released.
Thanks.
-
Support OrderBy and OrderByDescending in Nested Arrays
For example in a document structure such as:
{
"id": "some id",
"things": [{ "value": "5" },
{ "value": "2" },
{ "value: "7" }]
}It would be great to be able to do something like:
queryable.Select(x => x.Things.OrderByDescending(y => y.Value)).AsEnumerable.FirstOrDefault();
105 votesAt this time we will mark this as unplanned. Will keep on our back log and monitor votes for this feature.
Thanks.
-
Compress stored data
Please compress data in place for more efficient use of storage.
For example, I recently exported the entire dataset from a collection and gathered the following stats:
DocumentDB Data Storage: 627 MiB (including hidden fields and other overhead I assume, but not Indexes)
Exported JSON: 461.72 MiB
Compressed JSON: 47MiBSo potentially a 10x saving in data storage size.
78 votesWe’re evaluating more compressed storage formats. Meanwhile, please consider using a client-side compression library for encoding fields/JSON fragments that are not used for querying.
-
Compress query results
Compress query results if requested by the client. This could significantly improve network throughput for large queries.
63 votesQuick update. This feature is still in plan. Will look to start work on this in H2 2020.
thanks.
-
stored procedures & functions in .NET (C#)
Would be great to have the option to implement stored procedures, functions and triggers in .NET (C#) as well.
56 votesThis is not on our roadmap and we have no plans for it long term.
Thank you for your suggestion.
-
The ability to reference JavaScript libraries (e.g. underscore) within server-side scripting
It'd be nice to be able to reference javascript libraries within server-side scripting. Something like an AMD or RequireJS loader.
For example:
var _ = require('lodash');51 votesMoving to unplanned (backlog). This was incorrectly labeled under review.
-
DISTINCT should use index if possible
Currently one can query distinct values from documents using the DISTINCT keyword like in relational SQL.
Example:
SELECT distinct c.myField FROM cRelated feature request: https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6719531-provide-support-for-distinct
Unfortunately current DISTINCT is rather unusable as it seems to do a full scan even if there is an index present on the field. This feature does save some bandwidth when you really-really-really need this feature, but the RU consumption part is borderline-unacceptable for production use.
Please consider improving the implementation to avoid full scan and use index, if possible.
41 votesWork for this feature is now planned. Will update when work on this feature starts and when it becomes generally available.
Thank you.
-
Execute read-only stored procedures on secondary replica
I have a many-to-many scenario close to the post below:
https://feedback.azure.com/forums/263030-documentdb/suggestions/6611247-support-cross-document-joins
I have multiple entities, and the relationships between them are saved as documents and can't be denormalized.
Instead of doing multiple queries against the DB, I'd like to wrap it in a stored procedure to save round-trip time.
However, current stored procedures can only execute on primary replica, so it would be slow if the users are from another region.
Is that possible to define some read-only stored procedures so that it can be executed in read regions?28 votesAt this time we are marking this item as unplanned. We will continue to revisit this request for further votes and activity.
Thank you for your request.
-
Filtered unique indexes
I need my unique indexes to work when a soft delete flag is set to zero so that only the active records will participate in the uniqueness constraint per partition. This also makes it easier to determine deleted records in the Change Feed.
26 votesWork for this feature is currently on our backlog and not in our current development cycle plan. We will continue to revisit this item in upcoming cycles and will update here if this item moves in plan.
Thank you for your suggestion and votes.
-
Text search in documentdb with accented characters
I've searched for an answer to this and can't find it...
What I need is support for something like a text-analyzer that allows similar accented characters (e.g. àáâãäå) to match their normal latin equivalent.
So searching for names like "Jose" will return results like "José"20 votesThis is not currently planned, but you can implement this with some code by storing a normalized form of the string (without accents) by using https://msdn.microsoft.com/en-us/library/system.string.normalize.aspx
Please see https://stackoverflow.com/questions/249087/how-do-i-remove-diacritics-accents-from-a-string-in-net for more details.
-
Allow us to define global unique keys across all partitions
Unique keys are scoped to partitions, but this makes it challenging to store data that's supposed to be globally unique like email address or mobile number. I ended up creating a traditional SQL Server table for this, but I'd like to migrate it to Cosmos DB.
19 votesWork for this feature is currently on our backlog and not in our current development cycle plan. We will continue to revisit this item in upcoming cycles and will update here if this item moves in plan.
Thank you for your suggestion and votes.
-
Support left join
We have a need for the current JOIN mechanism to allow for LEFT JOIN's.
So code like this:
SELECT
c.myId,
(IS_DEFINED(dm.code) ? tm.code : dm.code) as code
FROM c
JOIN dm in c.modelData
JOIN tm in c.modelData
WHERE c.partitionKey="8"
AND dm.dataScope = "default"
and tm.dataScope = "other"on data like this:
[
…{
"myId": "1",
"partitionKey": "8",
"values": [
{
"dataScope": "default",
"code": "1"
},
{
"dataScope": "other",
"code": "1a"
}
],
"id": "ba884879-9b9b-3ff2-dc08-ca6168892ca5"
},
{
"myId": "2",
"partitionKey": "8",
"values": [
{
"dataScope": "default",
"code": "1a"
},
{
"dataScope": "other",
"code": "2"
}
],
"id": "864625c2-50de-5d56-9626-26b04d8ff1f2"
},
{
"myId":18 votesThis work is planned. Tentative start for H2 2020.
Thanks.
-
date difference function in cosmos db
Right now there was no date diff function supported in cosmos
It will be great if date related functions are available in cosmos12 votesWork on this feature as has started. Will update here when complete.
Thanks.
- Don't see your idea?