What happens to database entries that are loaded into memory using DbContext and Load?

Question

I don't understand where the records are going after they are loaded using Load(). Where do these records get loaded? Are they accessible from the layers or tmp1 variables? Ultimately, the method returns the layers variable, but it does not seem like what is going on with query and dbContext is affecting the layers variable:

var layers = dbContext.DataLayer.Where(x => layerIds.Contains(x.DataLayerId)).ToList();

var tmp1 = dbContext.XYDateRelationshipUnderDI
    .Where(x => x.XYDatedDI.Dated && layerIds.Contains(x.XYDatedDI.DataFeature.LayerId))
    .ToList()
    .Select(x => x.XYRelationshipId);

var query = dbContext.XYValueHolder
    .Where(x => tmp1.Contains(x.XYRelationshipId))
    .Where(x => x.XYValues.Count > 0);

// ...

query.Where(x => x.XYValues.Average(x => x.X) > item.ThresholdValue).Load();

// ...

dbContext.XYDatedDI
    .Where(x => tmp1.Contains(x.XYRelationshipUnderDI.XYRelationshipId)).Load();

return layers;

Most examples I see online are related to using the Load method for a single entity or DbSet. I am very much a beginner with C# and Entity Framework so this bit of code in a file I am debugging has got me a little confused.

Please read [ask] and [format your code](https://stackoverflow.com/help/formatting). — jwdonahue, Feb 23 '21 at 04:21
@jwdonahue Thanks, I edited the question, I hope this is better. — dmrobotix, Feb 23 '21 at 04:34
In short they get loaded into memory. If you dont know what this does, then there is no need to use it. — TheGeneral, Feb 23 '21 at 04:40
@00110001 I inherited this code from my colleague who passed away very suddenly so they thought it needed to be used. This comment doesn't answer my question. — dmrobotix, Feb 23 '21 at 04:41
"*In short they get loaded into memory*" comment out the loads and see what happens — TheGeneral, Feb 23 '21 at 04:42
You've posted code fragments. It's not clear if they are all from the same method. If so, it seems the whole point is to return `layers`. Are you debugging to familiarize yourself with it, or is there a problem you need to solve? Newbs have a tendency to post [XY-Problems](https://en.wikipedia.org/wiki/XY_problem), hence the suggestion that you read [ask] and post an [mcve]. If you're in a debugger, you should be able to drill into all of the variables and see what's in them. — jwdonahue, Feb 23 '21 at 05:18

Jeremy Lakeman · Accepted Answer · 2021-02-23T06:09:33.270

The change tracker keeps track of each object instance loaded from the database. When objects are loaded, the change tracker links navigation properties together based on foreign key values.

For example, if your layers variable contains objects with foreign keys to anything loaded by those other .Load() calls, the related objects will be linked in memory.

Then when you modify the properties of an object, it's the change tracker that detects your changes, which is then used to generate sql to apply those changes to the database.

You can examine all objects in the change tracker from context.ChangeTracker.Entries(), or query loaded instances through their DbSet's via context.dbset.Local.

score 0 · Answer 2 · edited Feb 25 '21 at 17:15

Check the following:

https://stackoverflow.com/a/18032219/1559611

DbContext is an Entity Framework object, which results in IQueryable<T>, which is like a cursor to the data queried and it executes the query in real time, which is accessed via cursor.

Now, there are options to convert IQueryable<T> to IEnumerable<T>, which is base interface and refers to loading data in the memory.

When you call .Load() or .ToList(), the data is loaded into a memory structure in one go in something like List<T>. Only benefit of using something like Load() is child and referenced data is also loaded in the memory for quick access, by using Include

Check this too:

DbContext Explicit Loading

So the difference is loading in the memory structure explicitly or access it over cursor (lazy loading), both mechanisms have their pros / cons and specific use cases.

Both the data points are specific to the call, they are gone once call is over, until and unless there's a caching to retrieve it back, but generally Caching is useful for in memory data for something like dbcontext connection pool is used internally to avoid costly reinitialization.

Data loaded in memory is quick in various operations as there's no network call, all network penalty is in one time loading the data.
For cursor-based approach there's a network call to get every unit of data, though its small and can be chunked to avoid the excessive network calls but application can only work on data loaded in the memory

Thank you for this explanation and the links! – dmrobotix Feb 23 '21 at 18:07 — dmrobotix, Feb 23 '21 at 18:07

What happens to database entries that are loaded into memory using DbContext and Load?

2 Answers2