I want to implement a very basic auditing in hibernate, like that:
every auditable table should have these fields: insertedBy, insertedDate, changedBy and changedDate

whenever a row of the table is inserted/changed, those fields should be updated automatically.

I tried to adopt the auditing example in christians book:
So I listen to the onSave/onFlushDirty events.
But my question now is: how do I determine if any field of the entities table is dirty or not?
the onFlushDirty event listener will also be called, if I add a new entity to a subtable (e.g. for OneToMany relationships), but have not changed any field of the table.

Do I need to loop over all fields of the entity and compare the currentState and previousState arrays and ignore all Set/List, etc. types?

this seems quite akward - is there a more convenient way?

what I had not understood was this:
hibernate will also update the version of an entity A (and thus the version column in the table), if you only add an entity B to a set of entity A.
that is why onFlushDirty is also called in this case:

since the table will actually be modified by this operation (version column is updated), it is correct for my callback to set the changedBy date.

In my special case, I will consider to make the relation unidirectional, so that entity A has no set of B-entities any longer and thus is totaly independant of entity (and table) B.

As far as tracking time of creation/update of any entity it is very simple. you do not need to listen to any events at all. You can declare a timestamp as your version field and hibernate will update automatically that field with time of update taking time from jvm or db depending on your choice. See book "Hibernate Reference" from Hibernate version 3.2 (the latest so far) paragraphs 5.1.9 and 5.1.10 - they explain all of it. You can see it on site here:

[url]http://www.hibernate.org/hib_docs/reference/en/html/mapping.html[/url]

Be very careful with using timestamp fields instead of plain numbers for versioning.
You can run into some problems:

• Daylight savings time issues
• 2 updates could possibly be performed within one second

Daylight saving issue is a valid concern. However 2 updates in one second is not since timestamp's precision is up to milisecond, so it will work fine. It is very low posibility that 2 simultanious updates will occur at the same milisecond.

sorry, should of course read millisecond.

but even that is not true for all databases.
e.g. MS SQL server currently has an accuracy of only 0.33 ms
http://msdn2.microsoft.com/en-us/library/aa258277(SQL.80).aspx

so according to murphy's law that must fail :)

the DLST issue should go away when we only use GMT times in the database (what we should do anyway)