We actually do two things:
Assume we have Person, we generate LazyPropLoadPersonProxy, and every time
that we create new person, we create this proxy.
This one only handle lazy prop initialization, and it is not doing the
forwarding trick.
Second proxy is the standard lazy load proxy, which may perform forwarding.

Warning for non auto prop will work, yeah.

On Wed, Jan 13, 2010 at 7:23 PM, Fabio Maulo <[email protected]> wrote:

> mmmm... I know that field-level-access interception is a .NET limitation...
> perhaps we can log a WARN if the lazy-property is not a auto-property
> without limit the usage.
>
> Why the proxy should be different than session.Load ?
> In JAVA the proxy is the same (if I can recall it).
>
>
> 2010/1/13 Ayende Rahien <[email protected]>
>
>> Yes, basically.
>> Please note that it will not be the same proxy as returned from Load.
>> And that one will not have the leaking this issue.
>>
>> The reason to limit it to auto props is that this way we don't have to
>> deal with field level access interception.
>>
>>
>> On Wed, Jan 13, 2010 at 7:15 PM, Fabio Maulo <[email protected]>wrote:
>>
>>> That mean that session.Get will return a proxy is the class has
>>> lazy-properties ?
>>> The same for "from EntityWithLazyProperty" will return all proxy ?
>>>
>>> Why limiting the usage on auto-properties ?
>>>
>>> 2010/1/13 Ayende Rahien <[email protected]>
>>>
>>> I am looking at implementing lazy properties ( as the first step to
>>>> implement ghost properties ).
>>>> I am not sure that I really like the Java impl, in particular it relies
>>>> on having to do bytecode re-writing, and that is not something that I think
>>>> that we need.
>>>> Instead, I thought that we can ask the byte code provider to create a
>>>> proxy class for us is we have any lazy properties at runtime, and then we
>>>> can switch the mapped class with the given proxy type.
>>>> That, in addition of limiting lazy properties to auto props only, will
>>>> mean that we don't really have to do any bytecode manipulation.
>>>>
>>>> Thoughts?
>>>>
>>>
>>>
>>>
>>> --
>>> Fabio Maulo
>>>
>>>
>>
>
>
> --
> Fabio Maulo
>
>

Reply via email to