Hibernate version: 2.1.8

Name and version of the database you are using: FirstSQL 2.75

Converted our Swing-Based Desktop Publishing app to use Hibernate. Not only did lots of JDBC code go away, our object model is much cleaner now, and we're seeing noticeabe performance gains. Kudos for a great framework and a great book.

Now on to my question:

I'm looking for a way to have Hibernate nullify certain entity Ids after the entity has been deleted via cascade. For reasons not worth detailing here, it is not (elegantly) possible to null these values explicitly subsequent to the delete, as the references to the deleted objects are no longer conveniently available.

After experimenting with the onDelete() and postFlush() methods in the Interceptor interface, I have determined that this can not be easily be accomplished via callback in Hibernate 2.1.8.

Under Hibernate3, I see that there is a PostDeleteEventListener. This looks like it could be a perfect fit. I do plan on upgrading to Hibernate3 soon, but not for a couple weeks at least.

In short:

Is it possible to automatically null the id (and possibly ids of children) of an entity deleted via cascade under Hibernate 2.1.8?

Similarly, how could this same question be addressed in Hibernate3?

Thanks,
Thom

Maybe I -will- expound a bit, in case it helps answer the inevitable "Why the hell would you want to do that anyway?" question.

Entity A aggregates a collection of Entity B

One instance of entity B is removed from A. The instance is passed into an Undo operation, in case the user later decides that removing that B instance wasn't so smart.

A is saved, resulting in the deletion of B from the database. The B instance id remains unchanged.

User invokes Undo, resulting in the deleted instance being reinserted into A's collection.

A is again saved via saveOrUpdate(), with an Exception resulting from Hibernate's attempt to update a non-existent row for the deleted B instance. Since the id is non-null, saveOrUpdate() assumes that an update is appropriate, but the row has been deleted.

If the B instance has its id nulled (and the ids of children), then the saveOrUpdate on A will handle the situation correctly.

There is a setting in HB3 which enables this behavior. Alternatively you could use an Interceptor or Lifecycle callback.

Thanks for the (unbelievably) prompt reply.

I see you discourage the use of LifeCycle in HIA (Hibernate in Action), advice which seems sound to me.

How would post-delete identity nulling be accomplished using an Interceptor callback?

I tried (unsuccessfully) using onDelete(), and postFlush() didn't ever seem to be called with a reference to the deleted entity.

For the benefit of anyone that finds this thread, here's the Hibernate3 configuration setting Gavin mentions:

hibernate.use_identifer_rollback

If enabled, generated identifier properties will be reset to default values when objects are deleted.

eg. true | false

FYI: The manual contains a minor typo:

Manual: hibernate.use_identifer_rollback
Actual: hibernate.use_identifier_rollback

Is this setting also intended to set ID's back to null when the transaction in which the object has been saved (and thus in which the ID has been generated) is rolled back?

This does not seem to happen here. We worked around this by writing an Interceptor to do it, but of course it would be much more elegant if Hibernate could take care of this for us.