Offer eager loading strategies
I supposed that eager loading currently supports only single fixed strategy and except some rare cases this strategy always joins all eager loaded data to one huge record set - at least that is what I saw so far.
I described the impact of such eager loading on Stack Overflow: http://stackoverflow.com/q/5521749/413501
It would be nice to have some control over the way how eager loading is executed with possibility to define if eager loaded data should be joined into single result set with the main data or if they should be executed in separate query.
var data = context.Items
.Include(p => p.ParentItem, EagerLoadingStrategy.JoinQuery)
.Include(p => p.SubItems, EagerLoadingStrategy.SeparateQuery);
.Where(p => p.Id == 123);
Generated SQL executed in single roundtrip (the main difference between using separate LINQ queries) will look like:
/* Base item query with joined parent */
SELECT i.Id AS ...,
i.ParentId AS ...,
i.Name AS ...,
p.ParentId AS ...,
p.Name AS ...,
FROM Items AS i
LEFT JOIN Items AS p ON i.ParentId = p.Id
WHERE i.Id = 123
/* Separate query for children */
SELECT c.Id AS ...,
c.ParentId AS ...,
c.Name AS ...
WHERE c.ParentId = 123
It would be also nice to be able to set default strategy globally per context instance.
At the moment I'm not sure if there is another useful strategy for the eager loading but perhaps a community will find another.
Adam Łepkowski commented
Unfortunatelly NHibernate fetching strategies - does not work with IQueryables, only with NHibernate's query syntax.
The only possible way is to use include, but setting eager load for N:1 and some 1:N would be a nice perf. tuning.
Of course, we're talking about strategies defined with mapping!
I think that providing build in fetching stategies like that would be nice: http://www.udidahan.com/2007/09/16/fetching-strategy-nhibernate-implementation-available/
I totally agree. Also, if you have multiple 1-N relationships in a single query using current Include() implementation, the resulting query is huge and so is the result set. Performance obviously decreases as to be unacceptable.
Most of the times you have to Load (or LoadProperty) what takes additional roundtrips.
Nowadays there's not optimal resolution to this problem using pure EF. Developers have to load objects manually using stored procedures.
What you're proposing is completely reasonable and it amazes me how this wasn't a design issue from the first version of EF, since it affects performance so much.