When working with the data migrated from the Azure Table Storage to the CosmosDB Table API, we need to look at one more aspect.
In the article about migrating from ATS to CosmosDB Table API, we saw how just changing the connection string in the appconfig file helps us migrate the data to CosmosDB. There is no need to redeploy the application as such, and the application still continues to work.
But one important thing to look at is, we did not really upgrade the SDK to that of Cosmos DB. We are still using the Azure Table Storage SDK. Though it is not mandatory, it is definitely a recommended thing to do.
The Cosmos DB SDK for Table API communicated with the Cosmos DB with the native binary protocol that bypasses the gateway. We need to rebuild and redeploy our application because there are new assemblies to be used now from the NuGet packages.
Right-click and choose the Manage NuGet packages option. Search for Cosmos DB and select the Microsoft Azure Cosmos DB Table option. Install it and Visual Studio does the work for you. It will get it inside the database and add it to the required fields.
Now there are two namespaces, one for the old Azure Table Storage SDK and one for this new one, so we go to the code and change the using statements.
The statements that contain the Windows.Azure keyword refer to the old SDK so we replace it with the Microsoft.Azure.Storage keyword and Microsoft.Azure.CosmosDB.Table.
The same steps for replacing the using statements should be performed in the entity class. In our case, the Users entity class.
With this step completed, our code is actually pointing to the new SDK that we have provided and the code still compiles and displays the tables. As we saw, there was no complex change in the code, but just the change in statements to point to the SDK usage.
CONCLUSION
In this blog post, we saw how to upgrade to Cosmos DB SDK for better performance in our database and how it is so simple to change few small things and you are good to go.
Leave a Reply