Or to put it another way for you, nHibernate does not "handle" the
"re-parenting", it handles persisting the objects in your domain.
If you want to re-parent, then re-parent:
If it is one-to-many this should be able to be handled by:
child.Parent = newParent;
If it is many-to-many you may need to have a method like:
ParentA.RemoveChild(child);
ParentB.AddChild(child);
I have a one-to-many relationship which has inverse set on it and I defined
the following on the Child (Entry is the parent entity and EntrySplit is the
child):
public virtual Entry Entry {
get { return _entry; }
set {
if (_entry != value) {
if (_entry != null)
_entry.EntrySplits.Remove(this);
_entry = value;
if (_entry != null)
_entry.EntrySplits.Add(this);
}
}
}
Also I have these methods defined on the Parent in case I want to add or
remove on the collection:
public virtual EntrySplit AddSplit(EntrySplit split) {
split.Entry = this;
return split;
}
public virtual EntrySplit AddNewSplit(decimal amount) {
var split = new EntrySplit {Amount = amount};
AddSplit(split);
return split;
}
So if I want to "re-parent" something like this should work:
using (tx = Session.BeginTransaction()){
split.Entry = newParent;
tx.Commit();
}
Looks like nHibernate is doing it's job to me.
Chris
On Thu, Sep 10, 2009 at 11:23 AM, José F. Romaniello <[email protected]
> wrote:
> You want changes to be reflected in the persistence model, but you don't
> take care of what you have currently in memory.
> IMHO: this is an object operation, let nhibernate to take care to update
> the persistent model, but do the right in the object model.
>
> 2009/9/10 Paladin_za <[email protected]>
>
>>
>> I think NHibernate is a great ORM, but I can't help but feel that in
>> some cases the product forces me to manage persistence issues it could
>> have dealt with itself.
>>
>> My biggest gripe at the moment is the case of re-parenting.
>>
>> For example, I have a parent object with a collection of child objects
>> and I want to move one of the existing child objects to a different
>> parent object.
>>
>> From a SQL perspective this could be done with the simple update
>> statement UPDATE ChildTable SET ParentId = DifferentParentId where
>> ChildId = TheIDOfTheChildToMove.
>>
>> But Nhibernate refuses to make this easy. From what I can read on the
>> web, there are 2 solutions.
>>
>> First solution. Change the HasMany mapping on the parent object to use
>> CascadeAll. This lets re-parenting work fine, but breaks deletes. How
>> do we typically delete an object in our models, we set the
>> ChildObject.Parent reference to null and remove the ChildObject from
>> the Parent's ChildObjects collection. Now NHibernate de-references the
>> objects, but the data still remains in the database. Outcome =
>> Developer has to do database programming by calling session.Delete.
>>
>> Second solution. Change the HasMany mapping on the parent object to
>> use CascadeAllDeleteOrphan. Delete works great now. As per the
>> documentation. amazing. Except, re-parenting breaks. And we get the
>> stupid object would be resaved exception. To "fix" this the developer
>> must first "delete" the object from the session and then re-attach it
>> to the new parent object.
>>
>> The above solutions invariably require my domain model to have some
>> knowledge of the underlying data access implementation. This flies in
>> the face of persistence ignorance which Nhibernate champions in every
>> other area.
>>
>> Can someone please explain why this is even considered acceptable?
>>
>> I can only hope that someone wiser than me has a solution to this.
>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en
-~----------~----~----~----~------~----~------~--~---
