Cosmos supports both full SQL-like querying and point reads; the latter can be used when the partition key and document ID are fully known, and is a much faster and cheaper option than the equivalent query in SQL.
EF's query pipeline contains significant logic for detecting when a LINQ query can be executed via ReadItem. This works well for cases where the user is unaware of the query vs. ReadItem distinction, where queries are dynamically composed (and so some may yield ReadItem while others won't), etc.
However, this strategy can also sometimes make it difficult for users to know exactly when ReadItem will be used and when it won't. For example, adding any LINQ clause beyond Where, or changing a comparison to a non-comparison, will make EF fall back to regular querying;. More subtly, combining both WithPartitionKey and Where automatically causes EF to fall back to querying, as it's quite difficult for EF to know whether the two specified partition keys have the same values or not (see #38238).
To help with this, we could introduce a specific API that ensures only ReadItem is used; for users that want to enforce using the fast/cheap ReadItem alternative is always used, this would be a way to ensure that.
This could be added as an extension method over DbSet, i.e. await context.Blogs.ReadItemAsync(partitionKey, id) (or something else).
Note that EF already has FindAsync, but (a) that doesn't allow specifying a separate partition key, and (b) it returns already-tracked entities, which is a different behavior from querying.
Cosmos supports both full SQL-like querying and point reads; the latter can be used when the partition key and document ID are fully known, and is a much faster and cheaper option than the equivalent query in SQL.
EF's query pipeline contains significant logic for detecting when a LINQ query can be executed via ReadItem. This works well for cases where the user is unaware of the query vs. ReadItem distinction, where queries are dynamically composed (and so some may yield ReadItem while others won't), etc.
However, this strategy can also sometimes make it difficult for users to know exactly when ReadItem will be used and when it won't. For example, adding any LINQ clause beyond Where, or changing a comparison to a non-comparison, will make EF fall back to regular querying;. More subtly, combining both WithPartitionKey and Where automatically causes EF to fall back to querying, as it's quite difficult for EF to know whether the two specified partition keys have the same values or not (see #38238).
To help with this, we could introduce a specific API that ensures only ReadItem is used; for users that want to enforce using the fast/cheap ReadItem alternative is always used, this would be a way to ensure that.
This could be added as an extension method over DbSet, i.e.
await context.Blogs.ReadItemAsync(partitionKey, id)(or something else).Note that EF already has FindAsync, but (a) that doesn't allow specifying a separate partition key, and (b) it returns already-tracked entities, which is a different behavior from querying.