I am working with a historical database where rows are created instead of being updated when the state of an object changes.

I was wondering if there is a simple way to have hibernate create a new row, with the new values, when any of an object's properties change, rather than updating the existing row.

Also, the other thing I need to do is flag one boolean column in the old row to show that it is now an "expired" row.

Is there any simple way to do this with hibernate other than creating proxy classes to use with the interceptor interface? This seems like a very tedious task.

Thanks for any help!

Hi,

I'm working with temporal data, too.
Did you already find a solution for your issue?

Cheers,
Pierce

Christian, thanks for this. We're beginning to look into various ways of handling audit logging, and this is a very interesting technique. Not sure if it will work for us (in particular, I don't know if our old DB2/390 database can use these interception triggers"), but at a high level, I really like the concept. Just wanted to say thanks!

Yes, Christian's example looks like a good option, but in our case, we didn't want to change anything at all with the database (including views), but rather to leave it all to hibernate. What I did was:

1) I created a class that implements PreInsertEventListener, where there is a method called onPreInsert which returns a boolean value to let Hibernate know whether to go on with persisting the entity or not. By changing the return to TRUE, the object will not be persisted, even though it is dirty.

2) Then I do a session.delete on the object to make it transient, but first I intercept that by having a second class which implements the Interceptor interface--there's a method in there called onDelete where I set the object's ID to 0 before making it transient.

3) Finally, I reattach the object using a session.save and Hibernate automatically makes it persistent with a new ID, which means that it will be inserted as a new row when the transaction is commited.

I see two benefits this way.. First there's no need to create a second object because it will already be blocked from updating the old row, and when the ID is zeroed and reattached with a new ID, it becomes persistent as a new row without ever needing to create a second object. And also, it is all done within one transaction and session which is a benefit in many ways as well.

Hope this helps!

Sorry, I made a typo... The first step above uses the PreUpdateEventListener interface, not the PreInsertEventListener.

And also, I just thought of another possible option, although I'm not positive that it will work.. It should though... You can set all the properties of the class as update="false" in the mapping rathar than using the PreUpdateEventListener and this will also block any updates from occurring.

As for the expiration of the old row, we use a timestamp column which needs to be updated, and in this kind of situation you can set that to be the only column with update="true". Then you have many options for where to change that value and once it is changed, it will be the only column that gets updated. Then you can follow the other steps to reattach the object for insertion.

Hi 'lesuako',

would it be possible to provide me some sample code for the PreUpdateEventListener you are using? Do you have a PreDeleteEventListener, too?

Thanks,
Pierce

We implemented an historian based on the Audit Logging example in Chapter 8.3.2 in Hibernate in action, which may be an alternative to the Event Listener strategy.

This is what I did:
1.Created an Historizable Interface which all objects that uses the history functionality should implement (Can use just an empty interface)

2.Create an MyInterceptor class, which implements the Interceptor class


(The other methods defined in the Interceptor interface uses default implementation)


3.Enabling the Interceptor by adding configuration line in the hibernate-service.xml file, by setting the SessionFactoryInterceptor attribute




Hope this can help you!