Commented Unassigned: Querying navigation properties that don't have data loaded should query database instead of loading all data and querying in memory [1450]

Example: a database with 50,000 Customers. Each Customer is mapped M:1 to a Status table and the status can be one of 20 different statuses. Status has a navigation property to access Customers. Requirement is to allow users to search on "Live" customers only from a certain form. When coding this, it would not be unnatural for a developer to get the "Live" Status and then run all queries on Status.Customers. The problem with this is that it isn't obvious that this loads all "Live" Customers and then only queries in memory afterwards. This also means that these entities hang around in the change tracking and need to be checked for updates, which slows a whole load of stuff down and a lot of coders won't realise why it is taking so long.

I just discovered this because I was running some code which inadvertently loaded about half a million entities instead of the 450 odd that it actually needed. I spent ages trying to work out why my code was taking 12 seconds to do DbSet.Adds!!
Comments: __EF Team Triage:__ This isn't something we are planning to change the default behavior for but there are ways to get this 'extra lazy loading' behavior. Here is a great post series from Arthur that shows how to do it - http://blog.oneunicorn.com/tag/extra-lazy/. You should also take a look at the "Applying filters when explicitly loading related entities" section of this article http://msdn.microsoft.com/en-us/data/jj574232.