skip to Main Content

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…

  1. Document
  2. Resource (JSONDocument might be used)
  3. AccessCondition
  4. 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


  1. The Document and Resource 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 the IfMatchEtag or IfNoneMatchEtag property. As example here’s an upsert that only works if the etag matches:

    await container.UpsertItemAsync(resource, pk, new ItemRequestOptions()
    {
        IfMatchEtag = resource.ETag, //supply the etag yourself
    });
    
    Login or Signup to reply.
  2. V3 uses Newtonsoft.Json as serialization engine, you can have your own base class that replaces Resource and have the system properties:

    public class MyResource
    {
    
    [JsonProperty("id")] 
    public string Id { get; set; }
    
    [JsonProperty("_rid")] 
    public string ResourceId { get; set; }
    
    [JsonProperty("ttl")]
    public int? TimeToLive { get; set; }
    
    [JsonProperty("_self")] 
    public string SelfLink { get; set; }
    
    [JsonProperty("_ts")]
    [JsonConverter(typeof(UnixDateTimeConverter))]
    public virtual DateTime Timestamp { get; set; }
    
    }
    
    public class WorkPlay : MyResource
    {
    ....
    }
    
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search