Page 10 - MSDN Magazine, March 2019

Data Points JULIE LERMAN
A Peek at the EF Core Cosmos DB Provider Preview, Part 2
In the January 2019 Data Points column, I presented a first look at the Cosmos DB Provider for EF Core. This provider is still in preview and is expected to go live with the EF Core 3.0 release, so it’s a good time to prepare for it in advance.
In that first part, you read about why there’s a NoSQL provider for an ORM and learned how to perform some basic read and write actions for individual objects and their related data as defined by a simple model. Writing code that leverages this pro- vider isn’t much different than working with the more familiar relational database providers.
You also learned how EF Core can create a database and con- tainers on the fly for pre-existing Azure Database accounts and how to view the data in the cloud using the Cosmos DB extension for Visual Studio Code.
I took a sidetrack in my February 2019 column (msdn.com/magazine/ mt833267) to take a look at the MongoDB API of Azure Cosmos DB, although this isn’t related to EF Core. Now I’ll return to my previous subject to share some of the other interesting discoveries I made when exploring the EF Core Cosmos DB provider.
In this column, you’ll learn about some of the provider’s more advanced features, such as configuring the DbContext to change how EF Core targets Cosmos DB database containers, realizing embedded documents with owned entities and using EF Core logging to see the SQL along with other interesting processing information generated by the provider.
More About Containers and EF Core Mappings
Containers, also known as collections in the Cosmos DB SQL and Mongo DB APIs, are schema-agnostic groupings of items that are the “fundamental units of scalability” for Cosmos DB. That is, you can define throughput per container and a container can scale and be replicated as a unit. As your data grows, designing models and how they align with containers will impact performance and cost. If you’ve used EF or EF Core, you’ll be familiar with the default that one DbSet<TEntity> maps to one table in a relational database. Creating a separate Cosmos DB container for each DbSet could be an expen- sive default, however. But the default, as you learned in Part 1, is that all of the data for a DbContext maps to a single container. And the convention is that the container has the same name as the DbContext.
Let’s take a look at defaults and see which ones you can control with EF Core.
In the previous article, I let EF Core trigger a new database and container to be created on the fly. I already had an Azure account, targeted to the SQL API (which is what EF Core uses). Geo-redundancy is enabled by default, but I’ve only configured my account to use a single datacenter in the Eastern United States. Therefore, by default, multi-region writes are disabled. So whatever databases I add to this account, and any containers to those data- bases, will follow those overarching specs controlled by the account.
In the first column, I had a DbContext named ExpanseDb- Context. When configuring the ExpanseDbContext to use the Cosmos provider, I specified that the database name should be ExpanseCosmosDemo:
optionsBuilder.UseCosmos(endpointstring,accountkeystring, "ExpanseCosmosDemo")
The first time my code called Database.EnsureCreated on an instance of ExpanseDbContext, the ExpanseCosmosDemo database was created along with the default container, called ExpanseDbContext, following the convention to use the name of the DbContext class.
The container was created using the Azure Cosmos DB defaults shown in Figure 1. Not shown in the figure is the indexing policy configuration using the default, which is “consistent.”
These settings can’t be affected by EF Core. You can modify them in the portal, using the Azure CLI or an SDK. This makes sense because EF Core’s role is to read and write data. But one thing you
The EF Core Cosmos DB Provider is in preview. All information is subject to change.
Code download available at msdn.com/magazine/0319magcode.
6 msdn magazine
Figure 1 Azure Cosmos DB Defaults for Creating a Container