Migrating from LINQ to SQL to Entity Framework: Eager Loading

Migrating from LINQ to SQL to Entity Framework: Eager Loading : EasyCoded

Migrating from LINQ to SQL to Entity Framework: Eager Loading : EasyCoded — Wed, 08 Oct 2008 08:07:23 GMT

PingBack from http://www.easycoded.com/migrating-from-linq-to-sql-to-entity-framework-eager-loading/

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Jay — Wed, 08 Oct 2008 12:23:56 GMT

When is the next release of Entity Framework scheduled?

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Ido Flatow — Wed, 08 Oct 2008 13:22:51 GMT

Unfortunately, .Include supports loading only one related end, thus making us load each and every related end by code. I'd think that there should be something like .Include("*") to load all referenced entities, and event .Include("*/*") for getting all cascaded entities. If i'm writing a service that returns an entity with all related data, I won't want to start writing numerous lines of code, just to mention that "oh, yes, of course I want to return ALL the data of the entity".

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Paul Blamire — Wed, 08 Oct 2008 13:37:34 GMT

Nice work. Looking forward to the rest of this series

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Joseph F — Wed, 08 Oct 2008 19:04:46 GMT

Fantastic! I've always hated the way LINQ2SQL handled eager fetching. But, where is the strong typing. A string just doesn't seem like the ideal way of specifying this.

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

divega — Wed, 08 Oct 2008 19:22:37 GMT

Hello Ido,

Something like Include("*") is intentionally not supported. While the Include API makes it easy to modify a query for it to load related information, each related end that you add comes at a cost.

Loading multiple paths and/or multiple levels, very quickly results in extremely complex queries.

My recommendation is to eager load only what is needed, always adding related ends and levels one at a time. As soon as you see any performance degradation, go one step back and try using other techniques. Sometimes it may help to do explicit load (as an example, it is not necessary to expand all orders, only the one you are displaying details for).

Other times you may want to take advantage of the relationship fix-up that we do for tracked queries. As an example, you can load Orders and the corresponding OrderLines in two separate AppendOnly queries. Once you have loaded the results of both queries, the stack will have fixed-up all relationships, so you will find each order’s OrderLines collection is loaded.

Diego

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Craig Stuntz — Wed, 08 Oct 2008 19:46:44 GMT

How do you eager load properties of a subtype? For example, let's say I have a type Department which has a navigation property (0..1) Chairman of type Employee. Some of the employees are Managers. Managers has a Supervises property which returns a list of Employees. When I eager load the department Chairman, I would also like to eager load all Employees supervised if the Chairman is a Manager.

In other words, something like this (I'm making up the syntax):

.Include("Chairman").Include("(Chairman as Manager).Employees").

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Mark Smeltzer — Thu, 09 Oct 2008 00:33:35 GMT

Regarding the use of strings... here is a comment I posted on the EF design blog a few days ago:

Hey Guys,

It would be really helpful if the code generators could generate a layer of abstractions that contained all of the string constants that are used in the attributes. Currently, it is a real pain that we often need to use string constants when doing things like eSQL or Include()'s.

I wrote my own little utility to parse through the XML bits, and generate classes to do the job for me, but it would be great if this were available for everyone as part of the toolset.

The classes I generate a just a series of nested static classes that allow me to write things like "MyDbContextMetadata.Entities.Customer .Properties.PhoneNumber.PropertyName" or "MyDbContextMetadata.Entities.Customer .Relationships.Supplier.Properties.Id.PropertyName".

That stuff is certainly a bit verbose, but the key benefit is that when model changes so will the metadata structures. Thus, any invalid metadata references will generate compilation errors rather than runtime errors.

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Travis Plummer — Thu, 09 Oct 2008 17:47:24 GMT

I second the request by Craig Stuntz. Self joins with subtyped nodes are common and we don't want to recursively load these relationships. When I give the children\nav property name with include, why can't it resolve n levels deep for me?

Thanks,

Travis

Weekly digest of interesting stuff

Steve Strong's Blog — Fri, 10 Oct 2008 12:51:54 GMT

Weekly digest of interesting stuff

Migrating from LINQ To SQL to the Entity Framework

Swiss MSDN Team Blog — Mon, 13 Oct 2008 15:48:44 GMT

Since the release of the Entity Framework, Microsoft got a number of requests for details and best practices

Migrating from LINQ to SQL to Entity Framework: Deferred Loading

ADO.NET team blog — Thu, 16 Oct 2008 20:52:31 GMT

Last week, we covered Eager Loading and how to migrate LINQ to SQL based code that took advantage of

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Guy Hurst — Fri, 17 Oct 2008 21:27:16 GMT

Eager loading in EF apparently has limitations on SQL2000 - we weren't able to Include() nested levels, and had to use separate Load() calls after completing the initial query.

In other words, we had to use multiple sequential queries.

However, when we used SQL2005 as the underlying DB, with MARS enabled, the nested Include()'s worked fine. Does this mean EF requires MARS (Multiple Active Result Sets) to do nested Include()'s ? And by extension, does it therefore need MARS to fully support eager loading?

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Guy Hurst — Fri, 17 Oct 2008 21:45:56 GMT

Let me modify my previous comment by specifying that the nested Include()'s that failed were not just nested, but were to the same underlying table. Several Navigation Properties of the entity being queried were actually associating to the same underlying table, and this seems to have been the source of the conflict.

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

shawn — Mon, 03 Nov 2008 04:47:36 GMT

I'm in agreement with Joseph and Mark's comments, if we can get an option for strongly-typed Include statements to use as an option instead of strings that would be great. After using LINQ to get away from strings of SQL it is unfortunate to have to embed strings back in as part of Includes. It just seems a little brittle.

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Daniel — Tue, 17 Feb 2009 06:00:37 GMT

A few things I have noticed in the Comments, some said they didn't like the use of a string in the "include" (no strong typing), and I also saw someone say it does not support multuple levels of associated entities.

As far as strong typing the query as opposed to writing the table name in it, I haven't seen a clever way around that, the closest I can get is:

Instead of this:

Product firstProduct = db.Product.Include("OrderDetail").Include("Supplier").First();

Write this:

Product firstProduct = db.Product.Include(db.OrderDetail.CommandText).Include(db.Supplier.CommentText).First();

And as far as supporting multiple levels, you can write something like this:

Product firstProduct = db.Product.Include(db.OrderDetail.CommandText + "." + db.OrderDetailLevel2.CommandText).Include(db.Supplier.CommentText + "." + db.SupplierLevel2.CommandText).First();

You see, the "Include" accepts a "dot-delimited" list of an existing path of associated entities

Hope this helps somebody!

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

stuartle — Sun, 22 Feb 2009 14:03:55 GMT

I wrote a blog post last year about a possible way to use Include with expressions rather than strings in Entity Framework:

http://blogs.msdn.com/stuartleeks/archive/2008/08/27/improving-objectquery-t-include.aspx

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Jim Wooley — Mon, 13 Apr 2009 22:55:07 GMT

Daniel,

Instead of using the CommandText to supply a string representation of the object to be "Included", why not support an expression predicate as LINQ to SQL does in the LoadWith option. That provides a richer option as you can not only strongly type the child relationship, but can also add filtering as well. Thus you could have:

Product firstProduct = db.Product.Include(p => p.OrderDetail);

Product firstProduct = db.Product.Include(p => p.OrderDetail.OfType<ActiveOrders>());

Of course this would entail parsing more expression trees as part of the query evaluation, but could provide a much richer implementation.

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Non-Migrator — Sat, 16 May 2009 01:13:11 GMT

Since Entity Framework doesn't even support enumerations, why would people want to migrate away? I guess there are some advanced scenarios where a person would need to, but IMO, Entity Framework just isn't developed enough yet. Agree? Disagree?

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

Medyum — Fri, 22 May 2009 14:05:10 GMT

I also saw someone say it does not support multuple levels of associated entities.

As far as strong typing the query as opposed to writing the table name in it, I haven't seen a clever way around that, the closest I can get is:

Instead of this:

Product firstProduct = db.Product.Include("OrderDetail").Include("Supplier").First();

Write this:

Product firstProduct = db.Product.Include(db.OrderDetail.CommandText).Include(db.Supplier.CommentText).First();

And as far as supporting multiple levels, you can write something like this:

Product firstProduct = db.Product.Include(db.OrderDetail.CommandText + "." + db.OrderDetailLevel2.CommandText).Include(db.Supplier.CommentText + "." + db.SupplierLevel2.CommandText).First();

You see, the "Include" accepts a "dot-delimited" list of an existing path of associated entities

Hope this helps somebody!

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

hikaye — Sat, 04 Jul 2009 22:28:18 GMT

This is fantastic. I am going to add it to my sites. Thanks!

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

ssk sorgulama — Thu, 23 Jul 2009 17:38:36 GMT

Fantastic! I've always hated the way LINQ2SQL handled eager fetching. But, where is the strong typing. A string just doesn't seem like the ideal way of specifying this.

re: Migrating from LINQ to SQL to Entity Framework: Eager Loading

zerrin egeliler — Thu, 23 Jul 2009 19:53:09 GMT

This is fantastic. I am going to add it to my sites. Thanks!