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 <[email protected]> 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 <[email protected]> escribió: > > > > > I posted a related question on SO: > >http://stackoverflow.com/questions/6114869/why-does-nhibernate-requir.... > > Is there something I am missing? Why is the "internal" attribute > > called for? > > > Thank you! > > -Michael > > > On May 5, 6:35 am, Fabio Maulo <[email protected]> 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 <[email protected]> escribió: > > >> You'll have to talk to Anders for that :) > > >> Steve Bohlen > >> [email protected]http://blog.unhandled-exceptions.comhttp://twitter.com/sbohlen > > >> On Wed, May 4, 2011 at 4:16 PM, Fabio Maulo <[email protected]> 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 <[email protected]> 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 > >>>> [email protected] > >>>>http://blog.unhandled-exceptions.com > >>>>http://twitter.com/sbohlen > > >>>> On Wed, May 4, 2011 at 3:56 PM, Diego Mijelshon > >>>> <[email protected]>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 <[email protected]> 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 > >>>>>> [email protected] > >>>>>>http://blog.unhandled-exceptions.com > >>>>>>http://twitter.com/sbohlen > > >>>>>> On Wed, May 4, 2011 at 10:08 AM, Ramon Smits > >>>>>> <[email protected]>wrote: > > >>>>>>> Can't you just convert private to protected? > > >>>>>>> On Wed, May 4, 2011 at 4:05 PM, cremor <[email protected]> wrote: > > >>>>>>>> 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? > > >>>>>>>> On May 4, 3:54 pm, Fabio Maulo <[email protected]> wrote: > >>>>>>>>> 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. > > >>>>>>>>> On Wed, May 4, 2011 at 10:39 AM, cremor <[email protected]> wrote: > >>>>>>>>>> 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 > > >>>>>>> -- > >>>>>>> Ramon > > >>> -- > >>> Fabio Maulo- Hide quoted text - > > >> - Show quoted text -- Hide quoted text - > > - Show quoted text -
