Hi,
just run into the issue #2 with NHibernate 3.3.3.4000.
Getting NonUniqueObjectException when saving bi-directional associations,
set with helper method like this:
public virtual void SetChild(Child child) {
Child = child;
child.Parent = this;
}
Are there any workarounds / estimations when it could be fixed?
I cameup with moving this code to extension methods, but I'm not very happy
this this solution.
Thanks
On Tuesday, August 2, 2011 7:15:41 PM UTC+3, Cheetah wrote:
>
> I'm trying to upgrade from NH 3.1 where I was using the Castle proxy
> factory with mappings containing lazy properties (so field interception
> proxies are at play here).
>
> A notable change that is causing me much pain is that in NH 3.2, if a
> field interception proxy is at play, there are two instances of every
> persistent object! There is the field interception proxy instance, and
> there is an instance which it wraps. This is causing me two major problems:
>
> 1) Any property mapped with an access="field.whatever" strategy has the
> field set only on the proxy, not on the wrapped object
> 2) Any method invocation is passed down to the wrapped object, it is not
> invoked on the proxy.
>
> This produces two failure scenarios:
>
> 1) Method invocations cannot see the field values set by the access
> strategy, because they were set on a different instance. So collections
> mapped that way all look empty from within method bodies.
>
> 2) Method invocations that somehow expose "this" often eventually cause a
> NonUniqueObjectException to be thrown. For example, a method on a parent
> object that is attaching a child (populating bidirectional relationships
> among other work) puts a reference to the wrapped instance into the child.
> When attempting to save the child,
> StatefulPersistenceContext.CheckUniqueness sees that the child's reference
> to its parent is not the same instance as the proxy instance the session
> knows about, and so throws the exception.
>
> I managed to work around failure #1 with a custom version of the
> FieldAcessor class that sets the field on both the proxy and the wrapped
> instance. It's an ugly hack, which disables the IL optimized version of
> the getter, but it seems to work.
>
> I cannot see any way to deal with failure #2, because I can't see how the
> wrapped instance can even find out if the proxy instance exists, much less
> get a reference to it.
>
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/nhusers?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
