Hibernate version: 1.2.1.GA

I have two entities mapped such that one has a collection of the other. The collection item entity has a reference back to the owning entity. The cascade is set up as all-delete-orphan.

I have this sequence of events:

1. Session1 is created, entities are queried, and the session1 is disposed.
2. A collection item is removed from the owning entity's collection.
3. The collection item's reference to the owning entity is cleared.
4. The owning entity is modified.
5. Session2 is created to save changes.
6. The collection item is manually deleted via session2.Delete().
7. Session2 is manually flushed.
8. The owning item is manually updated via session2.Update().
9. Session2 is manually flushed again.

I then get "StaleStateException: Unexpected row count: 0; expected: 1".

What appears to happen is that NHibernate attempts to delete the collection item twice -- once for the manual Delete() and once for the implicit cascade.

Shouldn't cascade deletes be smart enough to know that an entity it's trying to delete due to cascade rules has already been deleted earlier in the session?

That's the delete-orphan part that does this for you and if I recall correctly I read somewhere in the document where it says you really need to know an entity in a collection is not being manipulated somewhere out of scope of the collection it belongs to.


Farzad-

Maybe we'll have to get rid of the delete-orphan cascade. We have cascade deletes at the database level for everything mapped for NHibernate to cascade delete, and we need to keep support for manual deletions of dependent entities combined with other updates to their owners in the same session. For us, manual deletes will occur as often or more often than cascaded deletes.

If you have cascade deleting at the database level, is there even a reason to have cascade delete in the NHibernate mapping? I.e. is it needed to prevent NHibernate from getting confused about what the database may do that it won't know about?

In certain use case Hibernate definitely has an assumption that it knows the truth about database, such as it complains if it goes to update something in database and it is not there anymore. I do understand that cascade deletes in a database level can be very useful but you need to treat hibernate in these cases. Definitely you can not mix this with any other delete option in hibernate. However, with selects it should be ok since hibernate can ignore missing relations. This become a lot more complicated if a second level cache is used.



Farzad-

The problem still seems to be NHibernate's fault. It should keep track of what has been explicitly deleted in a session so as not to get confused about expectations of its implicit actions (i.e. cascade deletes).

It sounds very restrictive to say that any use of cascade delete mapping on entities with bidirectional references forbids any explicit deletion of those entities subject to cascade deleting. We want to use explicit deletion under normal circumstances and intend cascade deleting to function as a safety net. The safety net shouldn't prevent you from doing the primary operation.

Thinking about this a little more, there seems to be two separate problems. The problem as reported is that an NHibernate session doesn't keep track of explicit deletes, and so gets confused when an implicit (cascaded) delete "fails" because the entity is no longer in the database. However, even with this issue aside, if NHibernate tries to delete something from the database and it's not there for any reason (whether it forgot that it already deleted it, or it was deleted externally), why should it care? If you want to delete something and it's already gone, then so what. The end result has still been achieved. This should not cause an exception, or there should at least be the option to ignore it and continue.

For those who are interested, I'm now using this hack to NHibernate to prevent the problem:

In src\NHibernate\AdoNet\Expectations.cs, class BasicExpectation, method VerifyOutcomeNonBatched(), change



to



Unless someone can give a good reason why this is a bad idea, please consider this change for the trunk ...