When using cascade="all-delete-orphan" NHibernate is deleting a child row that is not orphaned - it has simply been moved to a new parent.
using (var session = sessionFactory.OpenSession())
{
using (var transaction = session.BeginTransaction())
{
// Get the store we're moving him to
Store newStore = session.QueryOver<Store>().Where(...).SingleOrDefault();
// Get existing employee
Employee jack = session.QueryOver<Employee>().Where(...).SingleOrDefault();
// Do the move
jack.Store.Staff.Remove(jack);
jack.Store = newStore;
jack.Store.Staff.Add(jack);
transaction.Commit();
}
}
When the commit occurs, a single DELETE statement is generated to delete 'jack' from the database. This behavior would make sense if 'jack' had, in fact, been orphaned but he should now be happily assigned to his new store.
If I change the cascade to "all", the expected UPDATE statement is generated and 'jack' is happily reassigned as expected. However, this causes genuine orphaned rows to remain in the database which is not acceptable.
Is this a bug or is there something I am doing wrong?
Here are the classes:
public class Store
{
public virtual Guid Id { get; private set; }
public virtual string Name { get; set; }
public virtual IList<Employee> Staff { get; set; }
}
public class Employee
{
public virtual Guid Id { get; private set; }
public virtual string FirstName { get; set; }
public virtual string LastName { get; set; }
public virtual Store Store { get; set; }
}
and the FluentNHibernate mappings:
public class EmployeeMap : ClassMap<Employee>
{
public EmployeeMap()
{
Id(x => x.Id).GeneratedBy.Guid();
Map(x => x.FirstName);
Map(x => x.LastName);
References(x => x.Store);
}
}
public class StoreMap : ClassMap<Store>
{
public StoreMap()
{
Id(x => x.Id).GeneratedBy.Guid();
Map(x => x.Name);
HasMany(x => x.Staff)
.Inverse()
.Cascade.AllDeleteOrphan();
}
}
UPDATE
After some more testing on this it does seem to be a bug, in that the order of loading the objects alters the outcomes (note the Move Employee is done as above in both cases):
1) Load Store B, Load Store A, Find Employee in A.Staff, Move Employee to B ==> Employee is deleted (No exception is thrown, Employee is not reinserted)
2) Load Store A, Load Store B, Find Employee in A.Staff, Move Employee to B ==> ObjectDeletedException (deleted object would be re-saved by cascade (remove deleted object from associations))
The second case appears to be the scenario referred to by @Cole W and discussed here and here and a known limitation of orphan handling in NHibernate.
However, the first case appears to be a bug. In my understanding there should not be a scenario where the order in which objects are loaded alters the database changes made by NHibernate. It appears to be a bug that potentially causes data loss.
UPDATE 2
Given the inconsistent behavior that is dependent on load order and the potential for data loss I have logged this as a bug in NHibernate JIRA. The bug report has full code and mappings to demonstrate the problem.
