Skip to main content

Azure Tools - Azure CosmosDB Emulator

Highlights of  Azure CosmosDB emulator
Azure Services: Azure CosmosDB
Cost: free of use
How is delivered: Windows Service or Docker container, exposing web endpoint on a local port
Top 3 features:
  • #1 Docker support
  • #2 A web explorer similar with the one available inside Azure Portal for local documents 
  • #3 The option to delete all the data with only one click
Pain points:
  • #1 No consistency level supported
  • #2 Limited to 25 fixed containers or 5 unlimited containers
  • #3 Lack of support for other APIs 
Credits: Azure CosmosDB Team

When I first discovered the emulator support for Azure CosmosDB I was super excited. Azure CosmosDB is not cheap and for development teams is always a challenge when they need to share a data repository.
Usually, each person in the team is working on different areas of the project and needs a different data setup. By having an emulator the team has the possibility to focus on their own area and test it locally without deploying their own instance of Azure Cosmos DB database or container. Not only the development is smooth, but also the running cost of the development environment is lower.

As you can see above, the interface is clean and provides the things that you need in the first moment when you start the emulator - the connection string to connect to it. The Explorer is similar to the one that we have inside Azure Portal, allowing us to do any type of operations inside our containers. We even have the ability to define functions, triggers and stored procedures.
The support of writing queries directly inside the browser it's nice and I used with success to understand some concepts related to how to write queries. You can save the queries defined in the emulator, but we aware that they are saved inside Azure CosmosDB containers. This will generate an additional cost (~$0.77/day) but can be used as a common query repository by the team.
There is an option that allows us to reset all the data stored inside the emulator. Useful during development phases. There is also the ability to upload content from JSON, for cases when you need to prepare your local emulator with fresh data.

The speed and the performance of the emulator are not high, but it is more than enough for development and to play around. Locally I don't see an issue with lack of support of consistency level especially because you have only one instance - no replica.

To be able to activate emulators for Gremlin API, Cassandra API, Table API or MongoDB emulator you need to start the emulator from the command line and specify "/EmulatorMongoDBEndpoint" as the parameter for MongoDB. A similar thing you need to do if you want the emulator for the other APIs. Except for the SQL API that is fully supported, the rest of the APIs are partially supported.
The Docker support for the emulator is awesome and enable you to use the emulator in different and configurations.


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.