5

I'm using Hibernate with Xml mappings. I have an entity that has two fields creationDate and updateDate of type timestamp, that have to be filled with the current UTC time when the entity is persisted and updated. I know about the existence of the @PrePersist and @PreUpdate annotations, but i don't know how to use their equivalent in my Xml mappings.

Again, i was wondering if Hibernate somehow supports natively the update and creation time set.

Thanks

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
Mark
  • 67,098
  • 47
  • 117
  • 162

2 Answers2

9

I know about the existence of the @PrePersist and @PreUpdate annotations, but i don't know how to use their equivalent in my Xml mappings.

The Hibernate3 event architecture provides something equivalent and you could register listeners for PreInsertEvent, PreUpdateEvent or SaveOrUpdateEvent (see the org.hibernate.event package for a full list) to set and update the create/update dates.

Another approach would be to use an interceptor, either Session-scoped or SessionFactory-scoped and to set both createDate and updateDate in onSave(...), update the updateDate in onFlushDirty(...).


Update: I'm leaving my original suggestions below but I think that the right approach (should have been my initial answer) is to use an interceptor or the event architecture.

You could use the generated attribute of the timestamp to get creationDate and updateDate generated by the database on insert and on insert and update respectively:

<class name="MyEntity" table="MY_ENTITY">
  <id .../>
  <timestamp name="createDate" generated="insert" ... />
  <timestamp name="updateDate" generated="always" ... />
  ...
</class>

Refer to the section on generated properties for full details.

Option 1

It appears that timestamp doesn't support generatead so my suggestion won't work. Nevertheless, having read the documentation more carefully, my understanding is that timestamp is an alternative to versioning and I don't think that it's an appropriate choice for fields like createDate and updateDate (it may work for the later but that's not what timestamp is for).

So I would actually still use generated properties but with simple properties instead of timestamp:

<class name="MyEntity" table="MY_ENTITY">
  <id .../>
  <property name="createDate" update="false" insert="false" generated="insert" ... />
  <property name="updateDate" update="false" insert="false" generated="always" ... />
  ...
</class>

At the database level, this would require using a trigger for updateDate column. For the createDate column, using something like current_timestamp as default value would work nicely. But triggers are maybe not wanted...

Option 2

To avoid the trigger of the Option 1, a variation would be to use updateDate for versioning (and thus map it as timestamp):

<class name="MyEntity" table="MY_ENTITY">
  <id .../>
  <timestamp name="updateDate" ... />
  <property name="createDate" update="false" insert="false" generated="insert" ... />
  ...
</class>

Same approach as Option 1 for createDate, use a default value at the database level.

Option 3

See the top of this answer...

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
1

Timestamps in Hibernate are apparently always updated automatically when the entity changes, so you can't use a <timestamp> mapping for the creation date. However, you can store it as a simple java.util.Date property, initialized it with new Date().

For the update timestamp, try this:

public class MyEntity {
  ...
  private Date updateDate;
  ...
}

<class name="MyEntity" table="MY_ENTITY">
  <id .../>
  <timestamp name="updateDate" access="field" column="UPDATE_DATE"/>
  ...
</class>

Note that timestamp must come right after id in the mapping.

FYI here is a reference of the timestamp attributes.

Péter Török
  • 114,404
  • 31
  • 268
  • 329
  • You can control this behavior with the `generated` attribute. – Pascal Thivent Apr 14 '10 at 16:31
  • @Pascal The reference linked above states: "`insert`: the given property value is generated on insert, but is not regenerated on subsequent updates. [...] Even though `version` and `timestamp` properties can be marked as `generated`, this option is not available." – Péter Török Apr 14 '10 at 20:26
  • Indeed, you're right. I went too fast. And now that I've re-read the doc carefully, I even wonder if one should use `timestamp` for "regular" fields like `createDate` or `updateDate` (my understanding is that you should use `timestamp` for `versioning` and this explains why `generated` doesn't make sense for `timestamp`), this seems to be an abuse of `timestamp`. – Pascal Thivent Apr 15 '10 at 15:11
  • @Pascal True, albeit a pretty common one (judging from the number of examples I found on the web). Which is sort of understandable as the other options listed in your answer all are more complicated, requiring triggers/interceptors/event listeners... – Péter Török Apr 15 '10 at 15:31
  • To be honest, I find that the documentation on `generated` sucks, it's unclear and misleading. (BTW, I didn't mean to harass you with my comment, I made a big typo that I wanted to fix, hence the delete/repost). – Pascal Thivent Apr 15 '10 at 15:48
  • @Pascal That's what I thought, I didn't perceive anything offending in what you did :-) – Péter Török Apr 15 '10 at 16:22