I'm no sure about Hb behaviour but: - Property.IsLazy is lazy in the "large-sense" (as you can see in your impl you are using HasLazyProperties || HasUnwrapProxyProperties) - ToOne.UnwrapProxy (that is for both many-to-one and one-to-one) should be set in corresponding binder and then managed to differentiate between the two types of lazy (proxy/no-proxy).
Btw if you need something different there is no problem, what is important is add some comment to understand the difference. 2010/1/25 Ayende Rahien <[email protected]> > Before going further, I just checked, and if I turn to use UnwrapProxy > using the same Lazy mechanism, I am going to end up with pretty bad results. > I _have_ to be able to tell the difference between lazy and unwrap > properties. > How does unwrapped proxy work in Hibernate? > > > On Mon, Jan 25, 2010 at 11:55 PM, Ayende Rahien <[email protected]> wrote: > >> Fabio, >> Cool, I didn't know about that. >> One of the nicest things about NH codebase is that it keeps doing stuff >> for me. >> >> I added some comments for that. >> The reason that I did it this way is that I need to keep track of which >> properties are lazy and which properties are ghosts, since they have >> different behaviors. >> >> On Mon, Jan 25, 2010 at 3:49 PM, Fabio Maulo <[email protected]>wrote: >> >>> Oren, >>> Have a look to the existing impl./usage of ToOne.UnwrapProxy (available >>> for ManyToOne and OneToOne) and the usage of Property.IsLazy (getter). >>> With your solution we have a different impl., and hopefully one more NH's >>> specific feature, for property laziness (refer to lazy-prop one-by-one and >>> lazy-group talked in the other thread). Some additional comments, with the >>> prefix "NH Different behaviour" and/or "NH Different implementation", would >>> be useful to keep track of our differences during some future port from >>> Hibernate. >>> For example have a look to the comment in Property.cs at IsLazy getter. >>> As you can see, in PocoEntityTuplizer, previous to your change, all >>> lazyproperties was managed taking the "large" concept of lazy >>> (proxy/no-proxy) and the real behaviour was managed "more internally"; a >>> little comment 'here and there' would be useful. >>> >>> P.S. To differentiate ours "TODO" from the "TODO" coming from Hibernate, >>> I'm using the prefix "TODO NH:" >>> >>> P.P.S. I'm happy to see a long-waited feature now working in NH too, >>> thanks Oren. >>> >>> >>> 2010/1/24 Fabio Maulo <[email protected]> >>> >>> The same for one-to-one ? >>>> >>>> >>>> 2010/1/24 Ayende Rahien <[email protected]> >>>> >>>>> Not much when there is that level of hand holding :-) >>>>> >>>>> >>>>> On Mon, Jan 25, 2010 at 12:50 AM, Fabio Maulo <[email protected]>wrote: >>>>> >>>>>> Ups!!! pretty quickly despite SVN >>>>>> >>>>>> >>>>>> 2010/1/24 Ayende Rahien <[email protected]> >>>>>> >>>>>>> Implemented & committed >>>>>>> >>>>>>> >>>>>>> On Mon, Jan 25, 2010 at 12:22 AM, Fabio Maulo >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> Yes I know and for that reason is lazy="no-proxy". >>>>>>>> The many-to-one relationship has 3 possible lazy values : >>>>>>>> lazy="false" (this is to avoid lazy) >>>>>>>> lazy="proxy" (as we are working today) >>>>>>>> lazy="no-proxy" (the property will work as lazy-load but without the >>>>>>>> proxy) >>>>>>>> >>>>>>>> In the trunk we are "ignoring" the value no-proxy, interpreting it >>>>>>>> as lazy="false", but its behaviour should be exactly what you are >>>>>>>> implementing. >>>>>>>> >>>>>>>> >>>>>>>> 2010/1/24 Ayende Rahien <[email protected]> >>>>>>>> >>>>>>>>> This is not for avoiding lazy loading. >>>>>>>>> This is to allow lazy loading with the correct polymorphic type >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jan 25, 2010 at 12:11 AM, Fabio Maulo < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> I'm sorry I don't understand... >>>>>>>>>> We should have lazy="no-proxy" available for this scope. >>>>>>>>>> >>>>>>>>>> 2010/1/24 Ayende Rahien <[email protected]> >>>>>>>>>> >>>>>>>>>> Okay, >>>>>>>>>>> I just committed initial support for this. >>>>>>>>>>> Given the following mapping: >>>>>>>>>>> <class name="Order" table="Orders"> >>>>>>>>>>> <id name="Id"> >>>>>>>>>>> <generator class="assigned" /> >>>>>>>>>>> </id> >>>>>>>>>>> <many-to-one name="Payment" * >>>>>>>>>>> force-load-on-property-access="true"*/> >>>>>>>>>>> </class> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> <class name="Payment" abstract="true"> >>>>>>>>>>> <id name="Id"> >>>>>>>>>>> <generator class="assigned" /> >>>>>>>>>>> </id> >>>>>>>>>>> <discriminator column="Type" type="System.String"/> >>>>>>>>>>> <subclass name="WireTransfer" discriminator-value="WT"> >>>>>>>>>>> </subclass> >>>>>>>>>>> <subclass name="CreditCard" discriminator-value="CC"> >>>>>>>>>>> >>>>>>>>>>> </subclass> >>>>>>>>>>> >>>>>>>>>>> </class> >>>>>>>>>>> >>>>>>>>>>> The following test will pass: >>>>>>>>>>> >>>>>>>>>>> [Test] >>>>>>>>>>> public void CanGetActualValueFromLazyManyToOne() >>>>>>>>>>> { >>>>>>>>>>> using (ISession s = OpenSession()) >>>>>>>>>>> { >>>>>>>>>>> var order = s.Get<Order>(1); >>>>>>>>>>> >>>>>>>>>>> Assert.IsTrue(order.Payment is WireTransfer); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> There is one problem, though, and that is the identity map. >>>>>>>>>>> >>>>>>>>>>> public void GhostPropertyMaintainIdentityMap() >>>>>>>>>>> { >>>>>>>>>>> using (ISession s = OpenSession()) >>>>>>>>>>> { >>>>>>>>>>> var order = s.Get<Order>(1); >>>>>>>>>>> >>>>>>>>>>> Assert.AreSame(order.Payment, s.Load<Payment>(1)); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> This seems to all works. >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>>> BTW, I really don't like the force-load-on-property-access, how >>>>>>>>>>> about call it ghost="false" ? >>>>>>>>>>> >>>>>>>>>>> On Thu, Dec 31, 2009 at 11:32 AM, Ayende Rahien < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> I am trying to figure out if we can support the following: >>>>>>>>>>>> >>>>>>>>>>>> class Comment >>>>>>>>>>>> { >>>>>>>>>>>> public virtual Post Post {get;set;} >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> class Post {} >>>>>>>>>>>> class Article : Post {} >>>>>>>>>>>> >>>>>>>>>>>> And *not* generate a PostProxy for the property, but instead >>>>>>>>>>>> detect the property access, force a load to return the correct >>>>>>>>>>>> type. >>>>>>>>>>>> We can do it right now by specifying lazy=false, but that >>>>>>>>>>>> pre-load the entity, while I would like to try to get it to load >>>>>>>>>>>> only on >>>>>>>>>>>> access time. >>>>>>>>>>>> >>>>>>>>>>>> There are several potential problems with this: >>>>>>>>>>>> a) we need to replace the reference on first access, which means >>>>>>>>>>>> that the _parent_ must be a proxy as well. >>>>>>>>>>>> b) we disallow field access entirely. >>>>>>>>>>>> c) identity map issues? >>>>>>>>>>>> >>>>>>>>>>>> other thoughts? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Fabio Maulo >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Fabio Maulo >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Fabio Maulo >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Fabio Maulo >>>> >>>> >>> >>> >>> -- >>> Fabio Maulo >>> >>> >> > -- Fabio Maulo
