In terms of “lazyness” of a property, there are currently three different ways in which it can be mapped in NHibernate:
- lazy=”false” means that it’s not lazy at all – the property’s content will be loaded along with its owner object. This means additional data is always loaded when you load an object, and may mean additional sql queries, too.
- lazy=”proxy” means that the object contained in the property is loaded when any of its public members is accessed. This property will contain an instance of a proxy, which is an object that knows how to initialize itself on-access. It performs the initialization not by loading its properties but by loading an instance of a real object and redirecting its properties and methods to it. This is why everything on the class that is to be proxied needs to be virtual: proxy is an instance of a class derived from it, which is dynamically generated and has every public member overridden to support lazy-loading.
- lazy=”no-proxy” means that the property is lazy-loaded, but without a proxy. From what I’ve seen, here the lazy property iself is manipulated on the owner object so that it facilitates on-access loading. In any case, there’s no proxy and no duplicate instances. This feature is currently (in v3.0.0) buggy and it seems to work the same as the first option (lazy=”false”), just as it did in 2.0 when it was unsupported.
Each of the options has its bad sides: with proxies, you get duplicate objects and must make everything virtual on your data classes. In the non-lazy option, for each eager property a join is usually added in the sql query so that the property’s values are loaded at the same time, and the same goes for the property’s properties etc. Even worse, HQL queries don’t respect this joining method, they load the main table in one SQL query and then execute an additional query or two (or dozen) for each record to collect its related data – this is called the “N+1 selects” problem. Needles to say, using HQL for such queries is madness: in these cases, it is best to switch to Criteria API which does the joins properly.
And the bad sides of the no-proxy option? It doesn’t work… Other than that, it seems the perfect solution: no joins, no duplicate objects. If you ask me, I don’t want my data to be loaded on-demand at all. I don’t want the application to decide when it will load its data: if I fill a datagrid with one hundred objects and then the grid triggers lazy-loading on each of the objects in turn, this will create chaos. No, I want the application to break if it accesses data that was not explicitly loaded. But with the current implementation I have no choice: it’s either eager or proxy, and I’m choosing eager, for better or worse.
How about LINQ queries? In 2.x it was implemented over the Criteria API which means it knew how to join-load additional records. Not so in 3.x: now it behaves like HQL, N+1 selects all over the place.
So, what is there to do? It seems the only option left is to write all queries with explicit fetch statements for every non-lazy property… This would definitely solve the execution performance issue, but development performance would suffer: if I add a new non-lazy property, I’d have to rewrite all queries where it appears.
Ok, but if we’re using LINQ, it’s a dynamical query, right? It can be modified to include all required fetches. After some research, it turns out that there’s a solution that (at least on the outside) looks even elegant: use an extension method to do this. So, you would do something like:
session.Query<Person>().Where(…).EagerFetchAllNonLazyProperties()
or:
(from p in session.Query<Person> where … select …).EagerFetchAllNonLazyProperties()
Here’s one way this method could be implemented. Note that this is a somewhat hacked implementation and that there are probably some unsupported cases – one thing that is suspicious to me is that Criteria API joined the eager properties recursively while only the first level is covered here, so be careful. But it’s a good start... Preliminary tests were very promising ;).
public static IQueryable<TOriginating> EagerFetchAll<TOriginating>
(this IQueryable<TOriginating> query)
{
// hack the session reference out of the provider - or is
// there a better way to do this?
ISession session = (ISession)typeof(NhQueryProvider)
.GetField("_session", System.Reflection.BindingFlags.Instance
| System.Reflection.BindingFlags.NonPublic)
.GetValue(query.Provider);
IClassMetadata metaData = session.SessionFactory
.GetClassMetadata(typeof(TOriginating));
for(int i = 0; i < metaData.PropertyNames.Length; i++)
{
global::NHibernate.Type.IType propType = metaData.PropertyTypes[i];
// get eagerly mapped associations to other entities
if (propType.IsAssociationType && propType.IsEntityType
&& !metaData.PropertyLaziness[i])
{
ParameterExpression par = Expression.Parameter(typeof(TOriginating), "p");
Expression propExp = Expression.Property(par, metaData.PropertyNames[i]);
Expression callExpr = Expression.Call(null,
typeof(EagerFetchingExtensionMethods).GetMethod("Fetch")
.MakeGenericMethod(typeof(TOriginating), propType.ReturnedClass),
// first parameter is the query, second is property access expression
query.Expression, Expression.Lambda(propExp, par)
);
LambdaExpression expr = Expression.Lambda(callExpr, par);
Type fetchGenericType = typeof(NhFetchRequest<,>)
.MakeGenericType(typeof(TOriginating), propType.ReturnedClass);
query = (IQueryable<TOriginating>)Activator.CreateInstance
(fetchGenericType, query.Provider, callExpr);
}
}
return query;
}
