Question

Is it the correct behaviour of entity framework to load all items with the given foreign key for a navigation property before querying/filtering?

For example:

myUser.Apples.First(a => a.Id == 1 && !a.Expires.HasValue);

Will load all apples associated with that user. (The SQL query doesn’t query the ID or Expires fields).

There are two other ways of doing it (which generate the correct SQL) but neither as clean as using the navigation properties:

myDbContext.Entry(myUser).Collection(u => u.Apples).Query().First(a => a.Id == 1 && !a.Expires.HasValue);

myDbContext.Apples.First(a => a.UserId == myUser.Id && a.Id == 1 && !a.Expires.HasValue);

Things I’ve Checked

• Lazy load is enabled and is not disabled anywhere.
• The navigation properties are virtual.

Answer 1

EDIT:

Ok based on your edit I think i had the wrong idea about what you were asking (which makes a lot more sense now). Ill leave the previous answer around as i think its probably useful to explain but is much less relevant to your specific question as it stands.

From what you’ve posted your user object is enabled for lazy loading. EF enables lazy loading by default, however there is one requirement to lazy loading which is to mark navigation properties as virtual (which you have done).

Lazy loading works by attaching to the get method on a navigation property and performing a SQL query at that point to retrieve the foreign entity. Navigation properties are also not queriable collections, which means that when you execute the get method your query will be executed immediately.

In your above example the apples collection on User is enumerated before you execute the .first call (which occurs using plain old linq to objects). This means that SQL will return back all of the apples associated to the user and filter them in memory on the querying machine (as you have observed). This will also mean you need two queries to pull down the apples you are interested in (one for the user and one for the nav property) which may not be efficient for you if all you want is apples.

A perhaps better way of doing this is to keep the whole expression as a query for as long as possible. An example of this would be something like the following:

myDbContext.Users
   .Where(u=>u.Id == userId)
   .SelectMany(u=>u.Apples)
   .Where(a=>a.Id == 1 && !a.Expires.HasValue);

this should execute as a single SQL statement and only pull down the apples you care about.

HTH

---

Ok from what i can understand of your question you are asking why EF appears to allow you to use navigation properties in a query even though they may be null in the result set.

In answer to your question yes this is expected behavior, heres why:

Why you write a query it is translated into SQL, for example something like

myDbContext.Apples.Where(a=>a.IsRed)

will turn into something like

Select * from Apples
where [IsRed] = 1

similarly something like the following will also be translated directly to SQL

myDbContext.Apples.Where(a=>a.Tree.Height > 100)

will turn into something like

Select a.* from Apples as a
inner join Tree as t on a.TreeId = t.Id
where t.Height > 100

However its a bit of a different story when we actually pull down the result sets.

To avoid pulling down too much data and making it slow EF offers several mechanisms for specifying what comes back in the result set. One is lazy loading (which incidently needs to be used carefully if you want to avoid performance issues) and the second is the include syntax. These methods restrict what we are pulling back so that queries are quick and dont consume un-needed resources.

For example in the above you will note that only Apple fields are returned.

If we were to add an include to that as below you could get a different result:

myDbContext.Apples.Include(a=>a.Tree).Where(a=>a.Tree.Height > 100)

will translate to SQL similar to:

Select a.*, t.* from Apples as a
inner join Tree as t on a.TreeId = t.Id
where t.Height > 100

In your above example (which I’m fairly sure isn’t syntactically correct as myContext.Users should be a collection and therefore shouldn’t have a .Apples) you are creating a query therefor all variables are available. When you enumerate that query you have to be explicit about whats returned.

For more details on navigation properties and how they work (and the .Include syntax) check out my blog: http://blog.staticvoid.co.nz/2012/07/entity-framework-navigation-property.html