NH3.2.0: public virtual getter & backend field

[kriebb]

I think I'm missing something, I hope someone can take the time to
explain.

Again, I've taken a lot of time searching, but I cannot find a
solution:

Take the following mapping and imangine that the OrderInitiator class
has a Code property.

<class name="Pdc.Erp.Domain.OrderManagement.AbstractOrder"
table="GeneralOrder" abstract="true" >
...
<component name="OrderInitiator" access="nosetter.camelcase"
class="Pdc.Erp.Domain.OrderManagement.Components.Order.OrderInitiator"
>

</component
</class>

In the AbstractOrder.cs i have the following:

protected OrderInitiator orderInitiator;

public virtual OrderInitiator OrderInitiator {get { return
orderInitiator = orderInitiator ?? new OrderInitiator()}
set{orderInitiator = value;}

If I want to access the OrderInitiator Property, the field is being
filled up ok as NH3.2.0 should do, but when I access the
OrderInitiator property with code 20, it gives me the new
OrderIntiator() with a null code.

My guess is that something is happening with the proxy, it override
the virtual property and does not know that it should return the
backend field...., but I defined it with access="nosetter.camelcase".

It makes no difference if I put the acces="field".

Does someone know what I'm doing wrong or does it seems like a bug and
post it to Jira?

[kriebb]

bug posted... ? unless someone else got an idea? https://nhibernate.jira.com/browse/NH-2873

[Ricardo Peres]

I think the field must be protected, not private, so that subclasses
(proxies) can access it.

On Sep 6, 2:08 pm, kriebb <riebbels.kris...@gmail.com> wrote:
> bug posted... ? unless someone else got an idea?https://nhibernate.jira.com/browse/NH-2873

[kriebb]

Hi,

I thought that also,

But, even when it's protected (or private), the field is filled up!
But when I try to access the field, using my getter property, I gives
me a null value back :(

[Asher Newcomer]

I'm not sure of the cause of your problem, but the proxies can access private fields/properties using some reflection tricks.

--
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.

[kriebb]

Hi,

Thanks for replying

I just uploaded some extra information to the bug report.

Here is a direct link:
https://nhibernate.jira.com/secure/attachment/14074/strange.pdf

I'm trying to play now with accessors...

[Fabio Maulo]

All public properties of OrderInitiator are null then the component itself is null.

[kriebb]

Hi,

Thanks for replying.

I know the behavior when all of the properties of a component are null, then the component is null. That i'm sure off.

But in the previous version NH2.1 I could alter that behavior abit using the propertys.

I tell NH to map a field, with watever value is in the database, null or not.

Then I access it using the property. The property then can check it if it is null or not. if it is null, I'll give a new object back.

This behaviour now seems to me impossible. 

I map the field with access="field", and the property's logic to give me a new one back isn't accessed, it just gives me null.

I map the field with access="property", and all is well

I properably miss something here: why can't the proprety give me the value back of the field? Shouldn't it trigger the interceptor to invoke the real property?

Thanks for some explanation...

Kristof

[Nexus]

First of all i looked in the contributed test, i do not understand
what your test is trying to prove, you are working with lazy
properties there, what you are not doing here.

First of all i tried the nullpattern for the following class

internal class Person
{
private Name name;

protected Person()
{
}

public Person(Name name)
: this()
{
this.name = name;
}

public virtual Guid Id { get; set; }

public virtual Name Name
{
get { return name = name ?? new Name(); }
}
}

internal class Name
{
public string Firstname { get; set; }
public string Lastname { get; set; }
}

This worked without even giving an itch, so i really do not understand
what is the problem here.

If you do work with lazy properties be warned that even the
proxyvalidator will give you errors when trying to compile mappings
for not an auto property !!!, so the test you supplied is very very
strange

I think we need a clearer example before we can understand what is
going on.

Nexus

[kriebb]

The test is about a very simple thing:

Why does the Assert.IsNull detect an empty property? when it's clear
that it's not null. The proxy should give the call to the original
property, I would think and evaluate the field? It is the field that
is mapped through the property...

It seems from the explantion above, that lazy properties should only
be used with auto properties. if that is true, then it would be nice
to get an error...

With clearer example, what do you mean with clearer? A more life test
case?

[kriebb]

here is a more clear example:

https://nhibernate.jira.com/secure/attachment/14077/NH-2873.zip

See comments on:
https://nhibernate.jira.com/browse/NH-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

But check this project out. Set lazy to true => everything fails (but
one test)
<!--To fix the tests: just uncomment this and comment the one below
this => differnce: lazy=false must be true-->
<!--<property name="NickName" length="25" type="string"
column="nickname" access="property" lazy="false" />-->
<property name="NickName" length="25" type="string"
column="nickname" access="property" lazy="true" />

Related issue? Could be... Maybe i was mis-using the lazy auto
properties... and came to a bug... Maybe this is the same issue, but
now correctly mapped?

On Sep 10, 3:35 pm, Nexus <tommar...@gmail.com> wrote:

[Nexus]

As for the lazy properties path see http://ayende.com/blog/4377/nhibernate-new-feature-lazy-properties

"One last word of caution, this feature is implemented via property
interception (and not field interception, like in Hibernate). That was
a conscious decision, because we didn’t want to add a bytecode weaving
requirement to NHibernate. What this means is that if you mark a
property as lazy, it must be a virtual automatic property. If you
attempt to access the underlying field value, instead of going through
the property, you will circumvent the lazy loading of the property,
and may get unexpected results. "

[kriebb]

Okay, I understand: lazy properties are automatic properties.

Question about the lazy properties:

In NH2.1 we had lazy references (many to one). Are those also now lazy
properties? So only lazy if they are automatic? or is the behavior in
NH3.2 the same as in NH2.1

Please checkout the other project that I posted to JIRA, concerning
automatic lazy properties...

On Sep 12, 10:41 am, Nexus <tommar...@gmail.com> wrote:
> As for the lazy properties path seehttp://ayende.com/blog/4377/nhibernate-new-feature-lazy-properties

[Nexus]

It think this might be related to https://nhibernate.jira.com/browse/NH-2772