Hi Neal, There is also an extension method that allows you to write:
.Fetch(...).Eager() Does that help? Sent from my Android phone. On 30 Sep 2010 02:49, "Neal Blomfield" <[email protected]> wrote: I think the Default, Eager, and Lazy properties on QueryOverFetchBuilderBase should be methods. Properties indicate that the caller is interested in the result and therefore the value *will* be used; this contract is upheld by the compiler in that it will not let you call a property without assigning the result to a variable. Methods may be called and have the result discarded, which implies the caller is interested in the operation rather than the result, which is much closer to the intent with Default, Eager and Lazy. Currently the fetch behaviour for an association is specified as follows when using lambda queries via QueryOver: var post = session.QueryOver<Post> .Where( p => p.Id == Id ) .Fetch( p => p.Comments ).Eager .Fetch( p => p.Tags ).Eager .SingleOrDefault(); This works well where you are building up the query in one location ( as above ) or updating an interim variable as you capture the value returned from the property and carry on using it. When you want to apply the fetching behaviour in isolation and don't care about the value returned from the property you have to resort to creating an unused variable to hold the result of the operation: public class FetchComments() : IFetchingStrategy<Post> { public void ApplyTo<TSubType>( IQueryOver<Post,TSubType> query ) { var queryWithFetch = query.Fetch( p => p.Comments ).Eager; } } While this does not break anything, it adds noise to the code where it is not needed.
