Since, Microsoft.Azure.DocumentDB package has been deprecated, I am in the process of migrating our codebase to access CosmosDB from Microsoft.Azure.DocumentDB v2.11.6 to use Microsoft.Azure.Cosmos v3.31.1.
I have used below references and migrated some of the code.
Migrating from Microsoft.Azure.DocumentDb to Microsoft.Azure.Cosmos for data access. Not all options available
https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/migrate-dotnet-v3?tabs=dotnet-v3
https://elcamino.cloud/articles/2019-11-05-cosmos-net-sdk-v3-upgrade-guide-and-tips.html
But it looks like note all classes and functionality are available in new package.
For below classes, I couldn’t find any replacement…
- Document
- Resource (JSONDocument might be used)
- AccessCondition
- AccessConditionType
My codebase is heavily dependent of properties comes with these classes like id, Timestamp, SelfLink etc.
How can I achieve the same with new Cosmos package.
public class WorkPlay : Resource
{
[JsonProperty(PropertyName = "WorkTypeEnum")]
public string WorkTypeEnum { get; set; }
[JsonProperty(PropertyName = "MediaType")]
public string MediaType { get; set; }
[JsonProperty(PropertyName = "Product")]
public string Product { get; set; }
}
AccessCondition ac = new AccessCondition { Type = AccessConditionType.IfNoneMatch };
this._client = new DocumentClient(new Uri(this._endpoint), this._authKey);
ResourceResponse<Document> response = await this._client.ReadDocumentAsync(Item1.SelfLink, new RequestOptions { AccessCondition = ac });
public async Task DeleteItemAsync(string selfLink, string partitionKey)
{
await this._client.DeleteDocumentAsync(selfLink, new RequestOptions() { PartitionKey = new PartitionKey(partitionKey) });
}
One Solution, I can think of creating my own implementation of Resource and Document class and add all the required properties.
then the problem comes when I retrieve doc with new cosmos APIs, selflink is not being populated. Since my old code is heavily dependent on selflink, I am more interested in a solution where it can retrieve all properties as it is doing with DocumentDB.
2
Answers
The
Document
andResource
have no alternative. You can however easily create a class of your own that implements the default properties such (e.g.public string id { get; set; }
).I don’t know the exact reason, but I think it’s partially because the v3 allows you to implement your own serializer which would cause a generic class like
Resource
to fail due to a dependency with a specific serializer.As alternative to the
accessCondition
you should now use theIfMatchEtag
orIfNoneMatchEtag
property. As example here’s an upsert that only works if the etag matches:V3 uses Newtonsoft.Json as serialization engine, you can have your own base class that replaces
Resource
and have the system properties: