0

I'm trying to understand how EntityFramework Core manages data internally because it influences how I call DbSets. Particularly, does it refer to in-memory data or re-query the database every time?

Example 1)

If I call _context.ToDo.Where(x => x.id == 123).First() and then in a different procedure call the same command again, will EF give me the in-memory value or re-query the DB?

Example 2)

If I call _context.ToDo.Where(x => x.id == 123).First() and then a few lines later call _context.ToDo.Find(123).Where(x => x.id == 123).Incude(x => x.Children).First(), will it use the in-memeory and then only query the DB for "Children" or does it recall the entire dataset?

I guess I'm wondering if it matters if I duplicate a call or not?

Is this affected by the AsNoTracking() switch?

John Mackerras
  • 525
  • 1
  • 4
  • 10
  • What you really ask is how caching works in EF Core, not how DbContext manages data. EF always offered 1st level caching - it kept the entities it loaded in memory, as long as the context remains alive. That's how it can track changes and save all of them when `SaveChanges` is called. It *doesn't* cache the query itself, so it doesn't know that `Where(....).First()` is meant to return those specific entities. You'd have to use `Find()` instead. If tracking is disabled, no entities are kept around. – Panagiotis Kanavos Jul 08 '20 at 10:54
  • In Example #2 the queries are different though. `Include` forces eager loading, so the results and entities returned are different. There's no need to call that a second time though, if the first entity and context are still around. You could just iterate over the `Children` property and EF would load the related entities one by one. This is obviously slower than executing just 1 query, which is why `Include` is used to load all relevant entities once – Panagiotis Kanavos Jul 08 '20 at 10:55
  • This is explained in [Querying and Finding Entities](https://learn.microsoft.com/en-us/ef/ef6/querying/), especially [Finding entities using primary keys](https://learn.microsoft.com/en-us/ef/ef6/querying/#finding-entities-using-primary-keys) – Panagiotis Kanavos Jul 08 '20 at 10:56

1 Answers1

1

What you really ask is how caching works in EF Core, not how DbContext manages data.

EF always offered 1st level caching - it kept the entities it loaded in memory, as long as the context remains alive. That's how it can track changes and save all of them when SaveChanges is called.

It doesn't cache the query itself, so it doesn't know that Where(....).First() is meant to return those specific entities. You'd have to use Find() instead. If tracking is disabled, no entities are kept around.

This is explained in Querying and Finding Entities, especially Finding entities using primary keys:

The Find method on DbSet uses the primary key value to attempt to find an entity tracked by the context. If the entity is not found in the context then a query will be sent to the database to find the entity there. Null is returned if the entity is not found in the context or in the database.

Find is different from using a query in two significant ways:

  • A round-trip to the database will only be made if the entity with the given key is not found in the context.
  • Find will return entities that are in the Added state. That is, Find will return entities that have been added to the context but have not yet been saved to the database.

In Example #2 the queries are different though. Include forces eager loading, so the results and entities returned are different. There's no need to call that a second time though, if the first entity and context are still around. You could just iterate over the Children property and EF would load the related entities one by one, using lazy loading.

EF will execute 1 query for each child item it loads. If you need to load all of them, this is slow. Slow enough to be have its own name, the N+1 selects problem. To avoid this you can load a related collection explicitly using explicit loading, eg. :

_context.Entry(todo).Collection(t=>t.Children).Load();

When you know you're going to use all children though, it's better to eagerly load all entities with Include().

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
  • Thank you that gives me a much clearer understanding and a reason to remove AsNoTracking() from some of my querries. Your document reference points to EF6. Here is think to the EFCore version of the docs if anyone is interested: https://learn.microsoft.com/en-us/ef/core/querying/how-query-works – John Mackerras Jul 09 '20 at 07:48