Tuesday, June 13, 2017
Joda Time Auto Timestamping Issue on Grails 1 1 1
Joda Time Auto Timestamping Issue on Grails 1 1 1
Ive not upgraded most of my code to Grails 1.1.1 yet so I hadnt noticed this problem until it was brought to my attention by Manuel Vio on the grails-user mailing list.
I raised a bug a few days ago around the fact that GORM identifies Joda Time types (and presumably any non-default property type) as a one-to-one association. Up to now the only problem this caused me was that it means the Joda Time plugin has to do some slightly hacky tricks in the scaffolding templates to prevent crashes when Grails tries to render the properties as though they were associated domain instances only to find they have no id property. However, on Grails 1.1.1 the bug is causing a nasty failure on auto-timestamping.
Under Grails 1.1 you can use a Joda DateTime for an auto-timestamped fields:
DateTime dateCreated
DateTime lastUpdated
static mapping = {
dateCreated type: PersistentDateTime
lastUpdated type: PersistentDateTime
}
These behave exactly like the regular Date fields with those names, i.e. theyre set automatically on save and update. In Grails 1.1.1 the same class will fail on save with a GroovyRuntimeException Could not find matching constructor for: java.lang.Object(java.lang.Long).
There is a (somewhat strange) workaround - declare the timestamped fields as non-lazy!
DateTime dateCreated
DateTime lastUpdated
static mapping = {
dateCreated type: PersistentDateTime, lazy: false
lastUpdated type: PersistentDateTime, lazy: false
}
Digging into the Grails code a little I found that association properties have their getter wrapped in a lazy-loading proxy. Since GORM thinks Joda Time properties are associations, this happens to them. The auto-timestamping code initialises the properties using property.getType().newInstance(System.currentTimeMillis()). Unfortunately, because property is actually the lazy-load proxy rather than the real property property.getType() returns Object.
Available link for download
