BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Does LINQ-to-Entities really return different results depending on previous queries?

Does LINQ-to-Entities really return different results depending on previous queries?

Leia em Português

This item in japanese

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?

Rate this Article

Adoption
Style

BT