In this blog post, we will look at the resource model of Cosmos DB and then look at the resource properties, identifiers etc. which help to uniquely identify the documents.
In CosmosDB, every resource is actually a collection of resources. This works like, we have a Cosmos DB account which contains of databases which eventually contain data containers. These data containers are known as collections. The JSON documents are stored inside collections when working with SQL API.
Azure Cosmos DB account -> Databases -> Collections -> Documents -> Attachments
The collections further contain documents which when expanded can contain a variety of data. Documents contain attachments also like images etc. but when trying to use attachments for large data maybe BLOB (Binary large object), using attachments isn’t really a good option since it has a fixed limit of 2 gigabytes.
As an alternative Azure provides Azure BLOB storage to contain that BLOB data and the links to these BLOBs can then be stored as a properties in Cosmos DB account.
Documents -> Users -> Permissions
We also have users and permissions in Cosmos DB that is used for granular security. We have seen that we can use the master key to access all the resources, databases and collections across the data, but if we want access to specific data, we can use user permissions which grant the access only to particular resources.
Some of the Resource properties are :
Every resource has an id property assigned to uniquely identify it. however, if we do not specify it, Cosmos DB uses a default created id for a particular resource.
Apart from the id property there are many more auto-generated properties prefixed by underscore that show up when we create the document in Cosmos DB. They are:
Resource id. This is an id that is always set and can never change. Every resource has basically 2 IDs. The regular id which can be set and modified, and the resource id which cant be played around with.
This is the timestamp property which holds the date and time for the last update status of the resource.
Cosmos DB uses it internally to check for concurrency.This means when one user has made some changes, the etag property will change and the other user will get a prompt that this was modified recently by …
The etag property contains binary values so it always changes when the resource changes. This prevents one user from overwriting the other’s changes.
This property is the full path to the resource, nested resources and even the attachments.
Let us look at how it looks in the Cosmos DB.
So there are three way to identify a document.
- self link
- ID-based routing
Collection of all your resource ids. Its starts with dbs which is databases followed by the resource ids and then has /colls/ which stands for collections followed by collections resource id, then /docs for documents and finally ends with a slash to refer to the documents and resources contained within.
if we do not recall all the resource ids of the resources that we created, it is better to use ID-based routing which takes simply the ID which we can easily refer to and use. It also doesn’t have a terminating slash. We can simply use the collection and database ID and then the document ID.
It is best to use URI which uses URIConnectionFactory to create a URI. It has its own syntax to create a URI and we do not need to construct one by ourselves. It has a create URI method for all the types of data.
In case of document data, we use createDocumentUri(). It will take three parameters, database id, collection id and document id to create the URI for us.