In a recent blog post Stu Smith claimed that “LINQ-to-Entities will return different results depending on what previous queries you’ve executed!”. If true, this would make using Entity Framework much harder than necessary to use. We talked to Elisa Flasko of the ADO.NET Team to find out what’s really going on.
The case here is actually a misunderstanding on the part of the author. The second query that they author runs, var order, is actually a LINQ to Objects query, not a LINQ to Entities (or LINQ to SQL) query. The LINQ to Objects query is querying the data that was previously brought into memory by the first query, var alice.
Now the reason for the difference in results, is that LINQ to SQL supports Lazy Loading, while version 1 of the Entity Framework does not. So if you look at the first query the author only brings the customer entities into memory (in both LINQ to SQL and LINQ to Entities this is true). However, in the second query (orders) the author attempts to access the related Orders entities. Now Lazy Loading will then make a second trip to the database to retrieve this information, however the explicit loading in the Entity Framework means that it will not make extra trips to the database "magically" for you. Since the Orders are not in memory, when you execute the LINQ to Objects query on top of the LINQ to Entities results there are no Orders available. However, after the foreach (where the author specifically calls data.Orders - accessing the context and querying for all Orders in the database) the Orders are now in memory and therefore the LINQ to Objects can query over top of them.
All that said, we are enabling you to turn on Lazy Loading in V2 of the Entity Framework, however it will continue to be off by default. The reasoning behind this, is to ensure that a developer cannot accidently get themselves into a performance problem situation where the database is being hit N+1 times, which is can easily be case with Lazy Loading, rather they developer must explicitly tell the framework that they are not concerned about the performance impact of Lazy Loading.
So is this a major design problem or just a training issue?
Community comments
Follow-Up
by Stu Smith,
Re: Follow-Up
by Eugene Tolmachev,
Training issue
by Rui Craveiro,
Follow-Up
by Stu Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
I've put down a few more thoughts in a new article, in case anyone's interested:
www.hackification.com/2008/12/04/linq-to-entiti...
- Stu
Re: Follow-Up
by Eugene Tolmachev,
Your message is awaiting moderation. Thank you for participating in the discussion.
If you read the answer carefully, LINQ-to-Entities not implementing the lazy loading is all it comes down to. Realizing that your objects are more-or-less PONOs, it makes perfect sense that any collection on a retrieved entity will support only LINQ-to-Objects, although in the absense of "lazy" one would expect "eager".
I wish Microsoft didn't reinvent the wheel and instead implemented LINQ-to-NHibernate.
Training issue
by Rui Craveiro,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi,
Actually, both. Not so obvious APIs become inevitably training issues. Whenever something doesn't work as expected, training can be argued, but training is a workaround, not the problem.