When executing ICriteria.List, i get an accurate list back of object. There's one but: the first object in the list is not of the expected poco type (MyPocoClass), but something like CProxyTypeMyPocoClass_NHibernate_ProxyINHibernateProxy_System_Runtime_SerializationISerializable2.

When executing the same criteria.list in a seperate unit test, all instances inside the collection are of the expected poco type (MyPocoClass).

I can't find the difference between the implementation that goes wrong and the unit test that runs as expected.

Anybody got a clue what could be the reason of this, or otherwise a way to prevent this?

A proxy class is something that NHibernate creates as part of 'lazy loading'.
I'd say that your class is lazy loaded but you need to load the full object (ie eagerly fetch) to be able to retrieve its type using (typeof(MyPocoClass).

Your other (separate) unit test probably has code which does fetch eagerly or overrides the 'lazy=true' setting somehow.

From here, I'd say hit the documentation or a book. It's not easy but knowing about this proxy and lazy loading is essential study material. Hopefully the words I've used are enough to get you the answers.

I have the same problem as ronaldvd.

Every object created by the lazy loading mechanism is of the correct type except 1 here and there. It seems to always be the same one.

Here is a snippet of the code that I use to Lazy load a collection in a persistant class:



Please if someone found a solution I would very much appreciate any tips or help.

Thanks

Hi ronaldvd!

Probably you have requested this "bad" object before making ICriteria request - so it was already present in session cache in form of corresponding proxy - so when you made second request NHibernate return "existing instance" among newly created.

I figured out why the Proxytype objects is returned from my persistant collections.

It turns out that if you have another object with a link to the object in question, and the other object is loaded first: the item in the collection will be the CProxytype and not the entity itself.

In ohter words, if NHibernate session somehow already loaded the object before the object is loaded from lazyloading the collection: the item in the collection will be the CProxytype and not the entity itself.

I scrathed around in the Nhibernate source and in SessionImpl.cs there is a function: DoLoadByClass(System.Type clazz, object id, bool checkDeleted, bool allowProxyCreation)

the allowProxyCreation flag here might be a clue as to fix this problem.

Or alternatively, how do I get the actual entity associated with the first loaded proxy of the object? Ps, when I talk about the actual entity I talk about the instantiation of the class the proxy derives from associated with the proxy.

This is basically what IgorK said.

So how do we come past this?

Hi tman!

What real problem do you have with proxy? Maybe it will be easier to overcome this problem than trying to "avoid" proxy in collection? Proxy must behave very similar to "non-proxy instance" - we only have some problems with XML serialization (just made custom serializer) and with reflection access (just add some code to take proxy into account - to transfer Type from proxy to it's BaseType).

Hi IgorK

Thanks for replying and trying to help.

The software I developed does not like the CProxy object. It would be much harder to try and work around the problem than fix it at the source?

I guess what I was hopinig for is to be able to load the objects (the same instance if it was loaded before) without hassle.

I also use reflection quite a bit and I use events to propagate changes in my objects to all the GUI controls visualizing a particular object. This poses quite a problem when trying to make my code "proxy friendly".

Again thanks for helping.

Hi tman!

Hmm... I think the only way to avoid proxy creation is to switch lazy loading off for all the classes - it may be really hard, as it may lead to enormous data loading (if your object graph is large enough and you use "normal" object associations - not "custom queries in getters")...

A less invasive workaround is just to close the current session and open a new session just before executing the Nhibernate statement that returns a CProxyType. This clears the first level cache and the correct type is returned.

Regards,

Ward

And if performance is a problem when you've cleared the session cache you can use the Second Level cache for both objects and queries.

Cheers,

Symon.