Entity Framework Core Pitfalls - Getting a Single Record by Key

Introduction

One more for the EF Core pitfalls series. EF Core offers essentially two ways to get a record with a known primary key:

There are a few differences between these approaches, and also a couple limitations, which I'll cover here. I will use as example a blogging domain model, where a Blog has many Posts, each Post references its Blog, and a Post has many Comments.

Like in other tips, this may or may not be a pitfall, but there is a possibility that we are not counting on this.

Using Find/FindAsync Methods

Find/FindAsync methods are great, because they allow us to retrieve a single entity without needing to know what is the property (or properties) that map to the primary key. There is also an enormous advantage: if the said entity was already loaded from the current DbContext, meaning, if it exists in the first level/object cache, then it is returned immediately. In general, this is what we want, but there are two problems with this:

  • If the entity became stale, meaning, if changes happened in the database after the entity was loaded, then we have data that does not match what is in the database. We need to reload it by calling Reload or ReloadAsync on the entity entry for the context (Entry):
BloggingContext ctx = ...;

var post = ctx.Posts.Find(1);

//data became stale, let's reload
ctx.Entry(post).Reload();
ctx.Entry(post).Reference(p => p.Blog).Load(); //for a single reference, one to one or many to one
ctx.Entry(post).Collection(p => p.Comments).Load(); //for multiple references, one to many or many to many

A possible alternative for this is auto includes: we can configure certain references (one to one, many to one) and collections (one to many, many to many) to be loaded automatically for a certain entity, either in OnModelCreating or in a configuration class (IEntityTypeConfiguration<T>):

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Post>().Navigation(p => p.Blog).AutoInclude();
}

This causes the referenced Blog to always be loaded together with a Post. If we want to skip it for a particular query, we can apply IgnoreAutoIncludes:

var post = ctx.Posts.IgnoreAutoIncludes().Find(1);

Using the Queryable Extension Methods

Using the built-in First/FirstOrDefault/Single/SingleOrDefault extension methods works if we know the primary key property (or properties), which we normally do. We can also apply eager loading by chaining Include and ThenInclude methods:

var postWithBlogAndComments = ctx.Posts
    .Where(p => p.PostId == 1)
    .Include(p => p.Blog)
    .Include(p => p.Comments)
    .SingleOrDefault();

We should be aware that if we include many references/collections, we may end up with a cartesian explosion of data, which essentially means more data will be sent from the database than needed, but this is another subject.

Usage of the EF Core asynchronous extension methods FirstAsync/FirstOrDefaultAsync/SingleAsync/SingleOrDefaultAsync is also a viable option, for when we want a fully asynchronous solution.

In both cases, we should follow these guidelines:

  • Single/SingleAsync is for the case when we are absolutely certain that a record with the id exists, and is unique. If there are more than one, or if it doesn't exist, an exception will be thrown
  • SingleOrDefault/SingleOrDefaultAsync is for when the record with that said id may not exist, but, if it does, it is unique
  • First/FirstAsync is for when the condition will return at least one but possibly many entities, but we only care about the first one and in that case we should enforce ordering of the results - failing to do so when there may be many records is itself a pitfall
  • FirstOrDefault/FirstOrDefaultAsync is for when the condition may or may not return at least one entity

In general, the performance of First/FirstAsync/FirstOrDefault/FirstOrDefaultAsync is better than that of Single/SingleAsync/SingleOrDefault/SingleOrDefaultAsync: the SingleXXX variants actually ask for 2 records, and not just one: this is how they enforce uniqueness on the results. But in terms of semantics, the FirstXXX variants seem to imply that more than one record may exist, which is wrong if we are querying by primary key, so SingleXXX seems more natural.

Of course, this approach disregards the first level cache, meaning, a query will always be issued, entities materialised, etc. One possible solution for this might be check the local cache first, and only if the entity is not there do we go to the database:

var postFromCache = ctx.Posts.Local.FindEntry(1)?.Entity; //will return null of the entity is not in the cache

Local contains all entities that have been previously loaded for the context and FindEntry searches by key.

Conclusion

As you can see, even for a simple operation, we have many choices. Choose wisely, as it may affect your performance or logic. Hope you find this tip useful!

Comments

Post a Comment

Popular posts from this blog

Modern Mapping with EF Core

Image
Introduction In EF Core (as in most O/RMs) we can map and store multiple things: Objects that hold a single value, like int , string , bool , float , Guid , DateTime , TimeSpan , Uri , etc. These are (somewhat wrongly) called primitive types  and are always included inside some container, like the following Objects that hold multiple single values and which have an identity, for example, Customer , Product , Order . These are called entity types  and they must have an identity that makes them unique amongst all the other objects of the same type Objects that are structured to hold multiple values, but have no identity, such as Address , Coordinate . These are called value types  and are merely a collection of (possibly related) properties We can also have collections of the previous things There's more to it, of course, for example, it is even possible to represent  inheritance of entities , of which I talked about before , In this post I am going to cover so...
Read more

OpenTelemetry with ASP.NET Core

Image
Introduction I wrote a post not too long ago about the building blocks of telemetry , or distributed tracing , with ASP.NET Core. Now I'm going to talk about how we can see it working using an open source bundle, otel-lgtm . Mind you, this may not be 100% suitable for production, but for development purposes, it should be fine, all concepts apply, of course. I won't cover everything about OpenTelemetry here, but should hopefully give you some insights as to what's there and how you can make good use of it. First, lets see what some of the concepts are. If you're interested in learning more about metrics, I suggest having a look at my post on this topic . OpenTelemetry OpenTelemetry  (OTel) provides a single, open-source standard, and a set of technologies to capture and export metrics, traces, and logs from your cloud-native applications and infrastructure. OTel is both a standard and a reference implementation that builds on other standards, such as W3C Distributed Tr...
Read more

.NET 10 Validation

Note: this is an update to my original post . Introduction I wrote about  entity validation  in the past, the reason I'm coming back to it is that there are some changes in .NET 10, related to validation. Let's cover the original validation API and then explain what has changed. .NET Validation Validation is implemented in the System.ComponentModel.DataAnnotations namespace. I'll describe it first and then move to the small changes in .NET 10. .NET has featured a way to validate classes and their properties for a long time, the API is called  Data Annotations Validation , and it integrates nicely with ASP.NET Core MVC and other frameworks (not Entity Framework Core, as  I've talked recently , nor ASP.NET Core Minimal APIs ). It is essentially, but not just, based on a set of attributes, one interface, and a class that performs validations on a target class and its properties, from the validation attributes it contain. The base class for attribute validation is ca...
Read more