Update on Azure Cosmos DB Provider Limitations

[balukantu]

Hi Team,

We are eager to integrate our application with Cosmos EF core provider but I am a little worried about the limitations of it.
My application is using CosmosClient and we are planning to integrate EF core.

There are some basic requirements mentioned below.

• CRUD operations
• LINQ queries with few methods like Where, FirstOrDefault, OrderBy, etc.
• Data consistency

How would you recommend using the provider for production applications?

Thanks
Balu

[AndriySvyryd]

@balukantu What do you expect to gain from using EF instead of CosmosClient directly?

[balukantu]

Hi,

Please find the below mentioned features/ functionality between CosmosClient and FCCore.

CosmosClient
- User has to pass partition key for CRUD operations
- User can pass a query string to filter records, this query is executed across partitions
- It provides different isolation levels

EF Core
- How can we pass partition the key for CRUD operations?
- Do we have any isolation levels?
- How the filtering will be executed? across partitions or a single partition

[AndriySvyryd]

• How can we pass partition the key for CRUD operations?

It's derived from the entities, see docs

• Do we have any isolation levels?

Not yet, dotnet/efcore#17309

• How the filtering will be executed? across partitions or a single partition

You'd perform the filtering in the LINQ query. To specify a partition key explicitly see dotnet/efcore#17320

[balukantu]

Thanks @AndriySvyryd

I have gone through the documentation and identified the point Entity types with partition keys don't work correctly in some scenarios.

So Can't we work efficiently with partition keys in EFCore? or As it is mentioned, can you list out the scenarios where it will not work?

[balukantu]

You'd perform the filtering in the LINQ query. To specify a partition key explicitly see dotnet/efcore#17320

I installed 3.0 and 3.1.2 tried executing WithPartitionKey but looks like there is no method which accepts partition key.

Can you please let us know in which version it is available?

[AndriySvyryd]

@balukantu dotnet/efcore#17320 is still open, meaning it hasn't been implemented. It's in the Backlog milestone meaning that we don't plan working on it any time soon.

Usually you'd only need it when using a Resource Key for a particular partition key instead of a Master Key. If that's not the case you should be able to add a filter to the query, e.g. .Where(e => e.PartitionKey == "10")

[SarekaAvinash]

Hi
I'm using the EF Core Azure CosmosDB provider to communicate with the Cosmos Database.
As per my observations, in Microsoft.EntityFrameworkCore.Cosmos nuget package there is no method (ex: Add(), Update(),Remove()) which takes partitionkey as a parameter.

I have a class like:
public class Employees
{
public string EmpId {get;set;} // Act as a PrimaryKey
public string EmpName {get;set;}
public string DeptName {get;set;} // Act as a partitionkey
}

While Create/Update an item in the cosmos Container we do like: dbContext.Employees.Add(employeeObject); and dbContext.Employees.Update(employeeObject);
As per my observation:
However, while creating/updating the employees, we are passing the partitionKey(DeptName) value in the employeeObject. so it will create/update the given item(employeeObject) in the respective partition of the Cosmos Container.

But how about to acheive Get and Delete operations:
In EFCore, to fetch a record by Id, we have a pre-defined method called Find().
ex: dbContext.Employees.Find("EmpId") -> as we are not passing any partitionKey to the Find(), it will loop through all the partitions and fetch the record or else???
How it behaves actually?

[AndriySvyryd]

Making that work is tracked by dotnet/efcore#17310

[balukantu]

• How can we pass partition the key for CRUD operations?

It's derived from the entities, see docs

@AndriySvyryd , The Find() method on EFCore accepts the only primary to fetch the record from CosmosDB and we are not passing the partition key value. So how the execution of Find() method? Will it check all partitions and returns the record? or how the Find() method works?

Note: Except Find() method remaining methods accept the model as an input so the partition key can read from the model and the query is executed in the respective partition and returns the result.

Please correct if my understanding is not correct.

[AndriySvyryd]

@balukantu It will work as expected if the partition key is part of the primary key

[balukantu]

@AndriySvyryd , Here, The model has a partition on other property which is not a primary key.

Example:
Class
{
Property int CityId, ---- >PrimaryKey
Property string CityName -------> PartitionKey
}

Below is the query to find the city by Id.
context.Cities.Find(cityId)

The above LINQ query takes Id as a parameter and which is not a partition key. So, the question is, the query executed against all partitions? or how the execution will be?

[AndriySvyryd]

@balukantu The query will be executed against all partitions.

[Anu666]

Hi @AndriySvyryd

We are currently using Cosmos Client and planning on using EF Core provider for CosmosDB in our application. We had the below few questions regarding this. Hope you can shed some light on these.

1. Will EF Core provider would provide all the functionality which is provided by the Cosmos Client ?
2. If yes, would there be any performance improvement by switching to EF Core provider?
3. As our application is going to be in production soon, will there be regular updates and performance improvements?
4. As lot of the work is ongoing as per the thread above, would you recommend us to use EF Core provider in place of Cosmos Client?

Thanks

[AndriySvyryd]

@Anu666

Will EF Core provider would provide all the functionality which is provided by the Cosmos Client ?

No. Currently there are many features that aren't implemented yet and it's unlikely that we'll ever expose all of CosmosClient functionality

If yes, would there be any performance improvement by switching to EF Core provider?

Unlikely, it's built on top of CosmosClient. So by definition you won't be able to achieve better performance with EF Core than with CosmosClient.

As our application is going to be in production soon, will there be regular updates and performance improvements?

Yes, if there's enough demand for them.

As lot of the work is ongoing as per the thread above, would you recommend us to use EF Core provider in place of Cosmos Client?

I would say that the biggest benefit of using the EF Core provider is to be able to write a new app much faster if you are already familiar with EF. If you have a working app that uses CosmosClient there would be little benefit from switching.