[SPRNET-1478] Use lazy properties of NHibernate in Spring.NET Created: 18/Nov/11  Updated: 18/Apr/12  Resolved: 18/Apr/12

Status: Resolved
Project: Spring.NET
Component/s: Spring-NET-NH
Affects Version/s: 1.3.2
Fix Version/s: 2.0 M1

Type: New Feature Priority: Major
Reporter: Carlos Eduardo Nogueira Assignee: Steve Bohlen
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: 4d
Time Spent: Not Specified
Original Estimate: 4d
Environment:

Windows 7, Visual Studio 2010



 Description   

Hi,

I worked in a project where we had to use NHibernate's lazy properties feature. Our mapping class was perfectly fit for this feature, but NHibernate assembled the SQL queries along with the lazy columns (thus, the properties were eagerly loaded). To identify this problem, we logged NHibernate's Tuple.Entity namespace. The following entry is relevant:

"Disabled lazy properies fetching for XXXXX.XXX beacuse it does not support lazy at the entity level".

Support for lazy properties is determined according to the lazyAvailable variable in the EntityMetamodel class. This variable was always false because Spring.NET used ProxyFactoryFactory. Its IsInstrumented method implementation always returns false. To overcome this problem, we decided to set the proxyfactory.factory_class key in NHibernate's properties to NHibernate.Bytecode.DefaultProxyFactoryFactory (where the return of IsInstrumented method always returns true).

Shouldn't Spring.NET let NHibernate use its default DefaultProxyFactoryFactory class when the key isn't explicitly set?

In order to help out developers who may face this problem, we decided to post this issue on jira.



 Comments   
Comment by Steve Bohlen [ 18/Nov/11 ]

Thanks for posting this. As you have identified, our assumption is that "if you don't explicitly set the proxyfactoryfactory key we will infer that you mean to use Spring.NET's proxying infrastructure". This is why your not having set this value results in your getting Spring.NET's proxy instead of the 'default' proxy factory that is provided 'natively' OOB with NH.

The introduction of a built-in default proxyfactoryfactory with NH is a (relatively) recent occurrence and so prior to the recent release it was necessary to specify some proxyfactoryfactory for NH in all cases. Under this context, having Spring.NET default to using its own infrastructure for this in the absence of an explicit value being set was a reasonable decision/default. Rather than change this to use the built-in NH default proxyfactoryfactory if none is specified (which would be a breaking change for users of both Spring.NET and NH together), I think the better course of action would be for the Spring.NET proxyfactoryfactory to properly support the newer NH lazy-properties feature.

Comment by Shane Walters [ 13/Jan/12 ]

This is a surprise when you upgrade to NHibenate 3.2. We removed all the proxy factory settings only to discover much later that Spring was magically changing to it's own proxy factory. If it is left as is, it should be highlighted in the docs and release notes.

I'd personally prefer that Spring not be this magical.

Comment by Steve Bohlen [ 18/Apr/12 ]

Behavior changed to use the NH internal ProxyFactoryFactory instead of the SPRNET ProxyFactoryFactory as the default. The SPRNET ProxyFactoryFactory can still be explicitly configured to be used if desired (to preserve compatibility if needed, etc.).

Generated at Wed Jul 17 22:59:04 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.