Breaking change in NH3.2.GA bytecode provider according to NH3.1.GA + Castle Bytecode Provider

[Alexander I. Zaytsev]

Hi,

I have following snippet of code, which worked in NH3.1 with castle bytecode provider

public class SomeEntity 
{
    public SomeProperty { get; private set;} 
}

Now in NH3.2 I got excaption that this kind of types are invalid for proxying and I need to make these properties more visibly. It is annoying to change all of such properties.

[Neo]

You need to make the setter "protected" instead of "private", how else
could a proxy access it!?

On 13 Aug, 22:10, "Alexander I. Zaytsev" <haz...@gmail.com> wrote:
> Hi,
>
> I have following snippet of code, which worked in NH3.1 with castle bytecode
> provider
>
> public class SomeEntity
> {

>     public SomeProperty { get; *private set*;}

[Alexander I. Zaytsev]

Proxy needn`t acces or override it!. Firstly I've mapped it via backingfield. Secondly proxy needn`t catch to access to It is, `cause instance should be unproxied when I try to access to private members!

[Alexander I. Zaytsev]

Sorry I've mistaken in member definition, it is a 

public virtual string SomeProperty { get; private set;}

[Alexander I. Zaytsev]

Created issue in jira https://nhibernate.jira.com/browse/NH-2837

[santhosh]

Whats the solution for it? Dont we have private set?

[Tom Bushell]

Santhosh,

I ran into similar problems when attempting to upgrade to NH 3.2...

But I see your issue was summarily closed the next day - without
explanation - which kind of pisses me off.

There was a comment in a Stack Overflow question that said the NH team
is "in denial" about all the breaking changes with the new bytecode
provider, and I'm starting to agree.

-Tom

[Joseph Lam]

I'm also stuck at 3.1 due to a problem with NH proxy polymorphism.
Looking at the JIRA history and 3.3 road map the NH team seems to be
focusing mostly on LINQ stuff, and none of the outstanding issues
filed against the bytecode provider are assigned. I think it's worth
raising the awareness in the NH team about the seriousness of this
situation.

[Tom Bushell]

How do we go about raising their awareness?

-Tom

[John Davidson]

One way is to comment here, but better yet is to vote on the jira issue, and the best is to provide a proposed patch that passes all tests.

John Davidson

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To post to this group, send email to nhu...@googlegroups.com.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

[Gunnar Liljas]

I made a small test, modifying the validation routine to explicitly let private setters slip through, and it seems to work just fine. Object hydrating etc. already handles this well. It's the validation routine which is a bit to simplified, as far as I can tell.

/G

2012/2/16 John Davidson <jwdav...@gmail.com>

[Alexander I. Zaytsev]

I think this was made because of partial trust environments.

2012/2/20 Gunnar Liljas <gunnar...@gmail.com>

[Gunnar Liljas]

I think so too, but the validation could take that into account.

/G

2012/2/20 Alexander I. Zaytsev <hazzik...@gmail.com>

[cremor]

This was done because of lazy properties. Previously if you had a lazy
property with private set, you would only get a error in the log which
was very easy to miss. Now the validator complains about it so you
can't miss it.

Of course it's annoying if you don't need lazy properties since the
usual lazy classes (proxies) for associations can still work with
private setters. But it is easy to fix, just overwrite
DynProxyTypeValidator and add a "if (!accessor.IsPrivate)" condition
there before the call of "CheckMethodIsVirtual(type, accessor)".

On Feb 20, 10:34 am, Gunnar Liljas <gunnar.lil...@gmail.com> wrote:
> I think so too, but the validation could take that into account.
>
> /G
>

> 2012/2/20 Alexander I. Zaytsev <hazzik+nos...@gmail.com>

>
>
>
>
>
>
>
> > I think this was made because of partial trust environments.
>

> > 2012/2/20 Gunnar Liljas <gunnar.lil...@gmail.com>

>
> >> I made a small test, modifying the validation routine to explicitly let
> >> private setters slip through, and it seems to work just fine. Object
> >> hydrating etc. already handles this well. It's the validation routine which
> >> is a bit to simplified, as far as I can tell.
>
> >> /G
>

> >> 2012/2/16 John Davidson <jwdavid...@gmail.com>

>
> >>> One way is to comment here, but better yet is to vote on the jira issue,
> >>> and the best is to provide a proposed patch that passes all tests.
>
> >>> John Davidson
>

[Tom Bushell]

On Feb 21, 2:17 am, cremor <cre...@gmx.net> wrote:
> This was done because of lazy properties. Previously if you had a lazy
> property with private set, you would only get a error in the log which
> was very easy to miss. Now the validator complains about it so you
> can't miss it.

I agree - that's better than a silent failure.

But can you explain (or point me to an explanation) - why is there a
requirement to have a setter for all properties?

I've done most of my NH work with v2.1.2 (and FNH 1.0), and my entity
classes have dozens of "get-only" properties (mainly returning
calculated values, or simplified access to private members). But now
that's all broken with NH 3.2.

This is a pretty common pattern in OO designs - I'd think this would
be a breaking change for a lot of people.

-Tom Bushell

[Tom Bushell]

Joseph,

I got on JIRA for the first time this week, and spent a few minutes
trying to find some of these issues so I could vote them up. But was
unable to find any current ones either by casual browsing or specific
searches, so I must be missing something.

Can you point me to a couple of them, and explain how you found them?

Thanks,

-Tom Bushell

On Feb 15, 11:11 pm, Joseph Lam <jla...@gmail.com> wrote:

[Joseph Lam]

You can go into the ByteCode Provider component to see the 6 open
issues:
https://nhibernate.jira.com/browse/NH/component/10090#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponent-issues-panel

[cremor]

> But can you explain (or point me to an explanation) - why is there a
> requirement to have a setter for all properties?
>
> I've done most of my NH work with v2.1.2 (and FNH 1.0), and my entity
> classes have dozens of "get-only" properties (mainly returning
> calculated values, or simplified access to private members). But now
> that's all broken with NH 3.2.

You shouldn't need setters for *all* properties, only for the ones
which are mapped.

Creating JIRA issues won't change anything since this is the new (by
design) behaviour of NHibernate (there was already a lengthy
discussion on the development list about this).
As I've already said, it is very easy to get the old behaviour. Just
inject you own DynProxyTypeValidator.

[Gunnar Liljas]

I see no problem in raising (but avoid re-raising) JIRA issues for things that are "by design", since the design may be bad. In this case I think it is. I certainly understand the reasoning behind it, but the problem is that the validator(s) can't make informed decisions, based on the actual context (mapping etc.).

/G

2012/2/27 cremor <cre...@gmx.net>