Proxy in NHibernate 3.3.1.4000

[Arman]

Hello,

I am using Fluent Nhibernate 1.3 with Nhibernate 3.3.1 with SQlite database. 

Today i found out that no proxy is using at all when a lazy-collection loaded.

I have a User object that it have an IList of Order object. User has a Orders collection in it that is lazy. (be default all the one-to-many is lazy)

when i access User.Orders , nhibernate load all of its orders correctly and completely, but none of loaded objects is proxified. i mean loaded objects is pure objects not a proxy of that object.

this result in full update query when i call Session.SaveOrUpdate later, and full row update is not necessary at all and it takes long time too.

i should mention that i am using SQLiteConfiguration.Standard, every one-to-many and many-to-one relations is lazyload.

What's wrong ?!

[Ricardo Peres]

Is the Order class marked as lazy?

[Arman]

yes, i marked all of my domain class with LazyLoad() in their fluent mappint.

[Oskar Berggren]

2012/9/27 Arman <arman....@gmail.com>

Hello,

I am using Fluent Nhibernate 1.3 with Nhibernate 3.3.1 with SQlite database. 

Today i found out that no proxy is using at all when a lazy-collection loaded.

I have a User object that it have an IList of Order object. User has a Orders collection in it that is lazy. (be default all the one-to-many is lazy)

when i access User.Orders , nhibernate load all of its orders correctly and completely, but none of loaded objects is proxified. i mean loaded objects is pure objects not a proxy of that object.

NHibernate has at this point loaded all the data to create the Order instances -  why bother instantiating proxies for them? That would only create additional work.

 

this result in full update query when i call Session.SaveOrUpdate later, and full row update is not necessary at all and it takes long time too.

Are you detaching the objects from the session in which they were loaded?

/Oskar

[Arman]

i have another website with nhibernate 3.1 , and in any situation it load's proxified object instead of pure objects.

and no, i did not detach object from session, my project is an ASP.Net c# project with session-per-request approach. so objects loaded is attached to a session.

[Ramon Smits]

On Thu, Sep 27, 2012 at 10:24 AM, Arman <arman....@gmail.com> wrote:

this result in full update query when i call Session.SaveOrUpdate later, and full row update is not necessary at all and it takes long time too.

My guess is that you refer to that you get an SQL update statement which lists all columns? That has nothing to do with lazy loading and is default behavior. You want what NHibernate calls dynamic updates which result in update and/or insert statements that only contain values which are actually set/updated.

-- Ramon

[Arman]

All of my class is marked with dynamicupdate() too. 

i think because nhibernate does not use proxy , so it cannot find with property is dirty and which one is not. so it updates all of its property and all of its relations properties.

if i can turn on proxy , i think my problem would be solved.

On Thursday, September 27, 2012 11:54:08 AM UTC+3:30, Arman wrote:

[Oskar Berggren]

2012/9/27 Arman <arman....@gmail.com>

All of my class is marked with dynamicupdate() too. 

i think because nhibernate does not use proxy , so it cannot find with property is dirty and which one is not. so it updates all of its property and all of its relations properties.

No. Proxies are not important for dirty tracking.

If you do session.Get<MyType>(someId) you will also NOT get a proxy. And NHibernate will not issue an update statement unless you actually do change something.


On the other hand, there should be no reason to call SaveOrUpdate() if the objects are already attached to the session. Though it shouldn't normally cause a problem either.

If you do session.Get<Order>(someOrderId) for one of the same orders, in a session by itself and then flush without doing any deliberate changes, does it still update? Sometimes mapping irregularities cause NHibernate to think a property is dirty even though the application itself hasn't changed it.


For indexed collections there is also lazy="extra" to not load all collection members unless necessary. But again, I suspect the problem here lies elsewhere.

/Oskar