I have recently moved from 0.8.3.0 to 1.0.0.0.

It now seems that every occurrence of cascade="all-delete-orphan" within a collection declaration is now broken. While never seen before using 0.8.3.0, just the presence of cascade="all-delete-orphan" causes this runtime error:

NHibernate.HibernateException : You may not dereference an collection with cascade="all-delete-orphan"

When I change to cascade="all", the error goes away, but the intended behavior is of course missing. Is this feature, or behavior, really missing/changed/taken away in 1.0.0.0? Must I always explicitly remove all contained objects from a collection in order to not leave orphaned objects when their containing object gets deleted?

Anyone's insight would be most welcome.


--------------------------------------------------------------

Here is a snippet of one of the affected mapping files:


<class name="Model.Project, Aegis" table="project">

<id name="Id" column="id" unsaved-value="0">
<generator class="identity" />
</id>

<property name="Title" column="title" />

<set name="ProjectTasks" lazy="true" cascade="all-delete-orphan">
<key column="project_id"/>
<one-to-many class="Model.ProjectTask, Aegis" />
</set>

</class>

This is just a result of stricter checking in NHibernate to prevent potential problems. If you have a collection with all-delete-orphan, you cannot do this:

(if myEntity.Collection is not null before this code). Doing this will leave the old collection unreferenced and NHibernate will not be able to tell reliably which object the orphans belonged to.

For example, in this code:



it's not really clear whose orphans are to be deleted, either those of entity1 or of entity2.

So NHibernate checks that all orphan-delete collections are referenced by some entity when Flush happens and this causes the error you are getting.