subject

Hi,

I am new to hibernate. I would like to know what is the best way to insert current date to one of my column in the table. This column should be updated to current date whenever there is a change in any value of row.

i tried handling in java code and made a getUpdateDate() method which returns "new Date()". But this has a problem. while i make a new row, it inserts other values and then make an update call to update current date as the value "new Date()" changes the state of object to some microseconds.

You should look at using a <timestamp> mapping for the date field and Hibernate will take care of updating it for you whenever it persists the data. It will also use this field for optimistic locking...

What is your definition of "current date"? For some reason, Hibernate seems to think the current date is the date/time of the client. But what happens if you have 200 clients accessing the same database and their clocks are all different?

There really should be a mechanism for using the database server date, but unfortunately the <timestamp> mapping uses the client date, or in the case of a web application the application server's date. This works OK if you have a single application server, but is not a solid way to handle timestamps.

I have not found a clean way to use the database time other than doing a manual "select sysdate from dual" or equivalent for your database and then manually setting the timestamp before an update. But then you have to deal with different dialects manually.

Anyone have a cleaner solution?

I think you are right. I would need the server date and not the client date. This will pose a problem to me.

Doesn't hibernate have something by which it takes the date of the server to which the database is installed.

An option is to use underlying database triggers to maintain this particular field and map it as a read only property.

You could do the triggers, but besides being very tedious and requiring extra database development, you'd essentially be scrapping the built in optimistic locking behavior for a <timestamp>.

A much better solution would be to have the option for the built in <timestamp> functionality to update the database with "sysdate" or equivalent dialect specific function for the database's current date, with the caviat that after an update your object would contain a stale timestamp. That could easily be overcome with a refresh, but often after an update the object is discarded anyway.