DynProxyTypeValidator complaining about private property setters?

[cremor]

I just tried a build of the current trunk (coming from 3.2.0.Alpha2)
and was quite surprised that nothing worked any more because
NHibernate complained about many of my entities not being proxyable.

Example property:
public virtual SomeEntity SomeEntity { get; private set; }

Seems like in r5718 the DynProxyTypeValidator was changed to also
check non-public property accessors (line 57 from
"property.GetAccessors(false)" to "property.GetAccessors(true)"). I
see that it's needed to check protected/protected internal accessors
(so the previous code wasn't checking everything), but shouldn't
private accessors be allowed?

[Fabio Maulo]

yes if you don't want use lazy-properties.

You can disable the validator but then you have to know what will happen if you use lazy-properties.

--
Fabio Maulo

[cremor]

Oh, lazy properties, right. I didn't think about that because I've
never used them.

Is there a way to just disable that lazy property check? Because I
don't want to disable the whole proxy checking for sure.
If not, would it be possible to change that code so it does the check
for private accessors only if the property is really mapped as lazy
property?

[Ramon Smits]

Can't you just convert private to protected?

--

Ramon

[Stephen Bohlen]

That feels like (yet another) constraint on my object modeling dictated by my persistence choice (tail wags dog).  There are already several of these w/NH adoption; I'd prefer not to introduce yet another one if we can avoid it.

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Fabio Maulo]

The proxyValidator is injectable. You can implement your validation.

Then, perhaps, we can mix the validation with the mapping to check the possible problem.

NOTE: the problem is not in the class itself but where it is used.

--
Fabio Maulo

[Richard Birkby]

I don't remember seeing this breaking change in the release notes?

Richard

[Fabio Maulo]

More than a breaking-change it is part of a bug-fix related to not-set values when lazy-property is used.

It includes an improvement because now you can use lazy-properties even when are not auto-properties.

--
Fabio Maulo

[Diego Mijelshon]

Steve, do you know what the default behavior for EF "code-first" is when a many-to-one property is not virtual?

It loads as null and lazy load doesn't work.

I'll take NH's fail-early, simple restrictions any time.
 
    Diego

[Stephen Bohlen]

lol -- there is no doubt in my mind at all that our restrictions are almost guaranteed to be the least invasive of all of the options, but I'd *still* like to ensure that we try to measure ourselves by something more rigorous than "we're not as bad as MS" :D

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Fabio Maulo]

well... give me something to override private members on the fly (without use IL rewrite) and I'll remove that restriction ;)

--
Fabio Maulo

[Stephen Bohlen]

You'll have to talk to Anders for that :)

Steve Bohlen
sbo...@gmail.com
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen

[Fabio Maulo]

btw the note about the breaking change is in the releasenotes.txt since the beginning. ;)

--

Fabio Maulo 

[Michael Teper]

I posted a related question on SO:
http://stackoverflow.com/questions/6114869/why-does-nhibernate-require-protected-internal-visibility-on-auto-properties.
Is there something I am missing? Why is the "internal" attribute
called for?

Thank you!
-Michael

On May 5, 6:35 am, Fabio Maulo <fabioma...@gmail.com> wrote:
> btw the note about the breaking change is in the releasenotes.txt since the
> beginning. ;)
>
> --
> Fabio Maulo
>

> El 04/05/2011, a las 17:18, Stephen Bohlen <sboh...@gmail.com> escribió:
>
> You'll have to talk to Anders for that :)
>
> Steve Bohlen

> sboh...@gmail.comhttp://blog.unhandled-exceptions.comhttp://twitter.com/sbohlen

>
>
>
> On Wed, May 4, 2011 at 4:16 PM, Fabio Maulo <fabioma...@gmail.com> wrote:
> > well... give me something to override private members on the fly (without
> > use IL rewrite) and I'll remove that restriction ;)
>

> > On Wed, May 4, 2011 at 5:01 PM, Stephen Bohlen <sboh...@gmail.com> wrote:
>
> >> lol -- there is no doubt in my mind at all that our restrictions are
> >> almost guaranteed to be the least invasive of all of the options, but I'd
> >> *still* like to ensure that we try to measure ourselves by something more
> >> rigorous than "we're not as bad as MS" :D
>
> >> Steve Bohlen

> >> sboh...@gmail.com

> >>http://blog.unhandled-exceptions.com
> >>http://twitter.com/sbohlen
>
> >> On Wed, May 4, 2011 at 3:56 PM, Diego Mijelshon <di...@mijelshon.com.ar>wrote:
>
> >>> Steve, do you know what the default behavior for EF "code-first" is when
> >>> a many-to-one property is not virtual?
> >>> It loads as null and lazy load doesn't work.
> >>> I'll take NH's fail-early, simple restrictions any time.
>
> >>>     Diego
>

> >>> On Wed, May 4, 2011 at 11:12, Stephen Bohlen <sboh...@gmail.com> wrote:
>
> >>>> That feels like (yet another) constraint on my object modeling dictated
> >>>> by my persistence choice (tail wags dog).  There are already several of
> >>>> these w/NH adoption; I'd prefer not to introduce yet another one if we can
> >>>> avoid it.
>
> >>>> Steve Bohlen

> >>>> sboh...@gmail.com
> >>>>http://blog.unhandled-exceptions.com
> >>>>http://twitter.com/sbohlen

> > Fabio Maulo- Hide quoted text -
>
> - Show quoted text -

[Fabio Maulo]

If you can proxy something that we can't please let us know.
If you want you can disable, through configuration, the proxy
validator... then when you have some default(T) instead the exepected
value, please activate the proxy validator before file an new issue.
Thanks.

P.S. a question in SO, the same in twitter, a mail to dev-list....
wow! pretty URGENT matter.

--
Fabio Maulo

[Michael Teper]

Fabio, urgency is in the eye of the beholder, so that's neither here
nor there. Having the question in multiple places may not carry much
value, but having the answer be more discoverable, in my opinion,
would have value.

Your comment, unfortunately, doesn't really directly answer the
question. Can you either explain (or, point me to an explanation) of
why the internal attribute is required in addition to the protected
attribute in order for proxying to work? That's really all I am
asking. Going from private to protected internal is a semantic change,
and I want to understand what it is that I am paying the price for. In
effect, this change in NH requires that we either accept that auto
properties can no longer be private, or not use auto properties at
all, which would be a shame as it's nice syntactic sugar.

Thank you!
-Michael

On May 24, 4:42 pm, Fabio Maulo <fabioma...@gmail.com> wrote:
> If you can proxy something that we can't please let us know.
> If you want you can disable, through configuration, the proxy
> validator... then when you have some default(T) instead the exepected
> value, please activate the proxy validator before file an new issue.
> Thanks.
>
> P.S. a question in SO, the same in twitter, a mail to dev-list....
> wow! pretty URGENT matter.
>
> --
> Fabio Maulo
>
> El 24/05/2011, a las 17:42, Michael Teper <mte...@gmail.com> escribió:
>
>
>
> > I posted a related question on SO:

> >http://stackoverflow.com/questions/6114869/why-does-nhibernate-requir....

> >> - Show quoted text -- Hide quoted text -

[Fabio Maulo]

internal is not required. if you have an internal, to be proxiable it
need even protected.

--
Fabio Maulo

[Michael Teper]

Fabio, you are right. I could have sworn I tested that, but facts are
facts and I must eat crow. I must have misread the error message, but
I checked it now and it's perfectly clear.

In any event, it's still really quite a shame that we are losing
ability to have private setters that can be used safely in the
constructor (see http://confluence.jetbrains.net/display/ReSharper/Virtual+method+call+in+constructor
for consice explanation of why calling a protected setter in the
constructor may be a bad idea).

Thanks for setting me straight!
-Michael

[Fabio Maulo]

The only thing bad is that in .NET sealed is the default instead virtual.

--
Fabio Maulo