Hi,

I try to use Lifecycle. I want to use it to change a some data just before it is persisted. But, the Lifecycle methods are never called!

I have persitent object. something like this:



And I call update:



The object is persisted nicely, but onUpdate() is never called. What am i doing wrong?

Jaap

You did not read the API and reference doc :)
Have a look at interceptor for that.

I actually read both - and found interceptor not really suitable for my needs.

I would say that:
"Optionally, a persistent class might implement the interface Lifecycle which provides some callbacks that allow the persistent object to perform necessary initialization/cleanup after save or load and before deletion or update."

means my persistent class will get the opportunity to do some things before an update is actually performed by Hibernate. But the methods are not called. Interceptor is different and not suitable because it needs to be invoked explicitly.

But problably I do something wrong or I have misread the manual.

From the API.
Called when an entity is passed to Session.update(). *This method is not called every time the object's state is persisted during a flush*.

An object already associated with the session (ie loaded), does not need to be update(), this method will be silently ignored. In your cas, it's the case and onUpdate won't be called.

Hmmmm,

Still find it confusing - but found the solution in the manual anyway. It is so simple - I think like I have looked like a cow staring to it's fence...

Anyway - the reason why I wanted 'Lifecycle' in the first place is because of what i see as a bug in Hibernate. Every time an object persists - I want an 'updateDate' field be set to the system time. Therefor I have mapped a <timestamp> like this:


But when updating an object for the first time - hibernate throws an error. The actual query generated by hibernate is something like:


I don't know the details about JDBC (MySQL) but in plain SQL this is wrong. Updating an object for the first time means the the timestamp is NULL. So the query in that case should not be "= null" but "is null".

IMHO it should not be null, it should be null before the insert, which should set it for the first time.

For the concurrency functionality this would not matter if it is null of not - I think 'bug' are not the right words i choose. I have a legacy which cannot be implemented by Hibernate with the timestamp (just almost except this damn null value :-)

For database design - it is IMHO better to avoid to fill records with unnecessary info*. So if a field contains no information - keep it null! Most of the records in my case are only created - and never updated - so why waste this space?
The design 'rule of thumb' can be especially important when you use indexes (one large table has an index on update_date in my case).

*all my tables have standard creation_date and update_date columns - update_date should - as it name says - only be filled on update. But i see it is actually a specific implementation of timestamp by me - but still if you you tmestamp _only_ for versioning - avoid unnecessary information in the database.

Well you notice that timestamp is for optimistic locking, which makes it absolutely the wrong choice in your setup. I would suggest mapping this as a plain old property, and handling the setting yourself either in your code or in an interceptor. I would still prefer using triggers for such stuff, but I have a strange feeling you are on mysql ...

I would think that it is most natural to set the updatedTime to the current time when the row is INSERTed. I'm happy with current functionality.